Linux-5.18: replace readpages with readahead

Linux-5.18: replace readpages with readahead

The linux 5.18 commit 'fs: Remove ->readpages address space
operation' (704528d8) removes the address_space_operations operation
"readpages", which is replaced with the "readahead" operation
that was introduced with the 5.8 commit 'mm: add readahead address
space operation' (8151b4c8).

When readahead is called, the pages in 'rac' have already been added to
the lru caches and are locked. For each page that we get from the 'rac'
(i.e. from 'readahead_page(rac)'), we must unlock and put_page the page;
if we successfully populated the page with data, we also set
PageUpToDate.  If we don't process all the pages in 'rac', the caller
will handle cleaning up any remaining pages; we don't need to unlock/put
them or touch them at all.
  (See Linux Documentation/filesystems/vfs.rst)

Add an autoconf test to detect the presence of 'readahead' in the
address_space_operations structure.

For the implementation of readahead (which is contained in Linux's
osi_vnodeops.c):

Add new functions 'afs_linux_bypass_readahead' and 'afs_linux_readahead'
as replacements for 'afs_bypass_readpages' and 'afs_linux_readpages'
when the linux kernel supports the readahead operation.

Notes:
  In afs_linux_bypass_readahead, the pages are already locked and are
  already in the page cache, we just need to place the page into the
  iovecp.  The page's refcount will be decremented and will be unlocked
  when processing the read request.

  In afs_linux_readahead, the lrupages is needed in case a page is added
  to the cachefp's mapping in afs_linux_read_cache (which also handles
  unlocking the page).

  In afs_linux_readahead, if there is no tdc, we must still unlock the
  page otherwise the read process will wait on that page.

Change-Id: I6960a2fc14df85869c373f3e3afbf3ee5eb7228f
Reviewed-on: https://gerrit.openafs.org/14953
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>