xfs: support in-memory btrees

Online repair of the reverse-mapping btrees presens some unique
challenges.  To construct a new reverse mapping btree, we must scan the
entire filesystem, but we cannot afford to quiesce the entire filesystem
for the potentially lengthy scan.

For rmap btrees, therefore, we relax our requirements of totally atomic
repairs.  Instead, repairs will scan all inodes, construct a new reverse
mapping dataset, format a new btree, and commit it before anyone trips
over the corruption.  This is exactly the same strategy as was used in
the quotacheck and nlink scanners.

Unfortunately, the xfarray cannot perform key-based lookups and is
therefore unsuitable for supporting live updates.  Luckily, we already a
data structure that maintains an indexed rmap recordset -- the existing
rmap btree code!  Hence we port the existing btree and buffer target
code to be able to create a btree using the xfile we developed earlier.
Live hooks keep the in-memory btree up to date for any resources that
have already been scanned.

This approach is not maximally memory efficient, but we can use the same
rmap code that we do everywhere else, which provides improved stability
without growing the code base even more.  Note that in-memory btree
blocks are always page sized.

This patchset modifies the kernel xfs buffer cache to be capable of
using a xfile (aka a shmem file) as a backing device.  It then augments
the btree code to support creating btree cursors with buffers that come
from a buftarg other than the data device (namely an xfile-backed
buftarg).  For the userspace xfs buffer cache, we instead use a memfd or
an O_TMPFILE file as a backing device.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNJ0jkACgkQ+H93GTRK
tOsJfw//dADzydU7t6ckRdQiVLGmXm+xQJoyF444vg+VN0d4ORWQUDGQWUKvvGNb
LPJ4mA2PPz0RgVgZ/XVwOWYAhsMmEq69qvYSJCmtxUpJKhGarA0jsH1B/NWofhv+
/8NHD2ryI8BSgShDT7fh9a4P3x2cJnf6wfDwRtUWFEaoQ8wJZcIZHTbeC4hZDvr1
8NIP5Ng9gqI5b94OsNqrZ2b/9++/XRG4LMM0o7l2bJhfNTkYvqojdrexJ0Ts8NHz
fq1l2kU0y1K11fCq80XL5dax6Y/F/59IG6+I6DWyhO26T1bf0LcIQVo+rN2VyFiv
7JKaMOHF/xdUZJ/v38Fvs+rX1q7N1pqS692FWhxOAIX9dRDIaNwe4UXjYly5Pmao
biDiGgW4v/d17exto/0rvh0Vgcg2ZqDjhaRPCzW0p9riOFNMU5Z9Cef3jqfhHQJM
JOMoVJ/KRMiAFZSFrN5aU0PlNeTaG2plIq9shI7ZcCtGgQ6Hq8o+mw9q5OBsTQef
M0TaZ1lC/X30EFhR2DPF8PmA6PrDrGNIXzI0i98LHsrbkR/DKQ5CGfufvkb8v86m
qF63c7lZ6NTgAXmReG0CCF1XROAMJn+WoClei1M9eQy3q67UdrLYc+k5HQlzxT05
612XI9eqoVUG63hcDXA5iigBnfu48+E1eb6amZx5fLaqebMwlF4=
=D3bO
-----END PGP SIGNATURE-----