xfs: detect mergeable and overlapping btree records

While I was doing differential fuzz analysis between xfs_scrub and
xfs_repair, I noticed that xfs_repair was only partially effective at
detecting btree records that can be merged, and xfs_scrub totally didn't
notice at all.

For every interval btree type except for the bmbt, there should never
exist two adjacent records with adjacent keyspaces because the
blockcount field is always large enough to span the entire keyspace of
the domain.  Concretely, the free space, rmap, and refcount btrees have
a blockcount field large enough to store the maximum AG length.

The bmbt is a different story due to its ondisk encoding where the
blockcount is only 21 bits wide.  Because AGs can span up to 2^31 blocks
and the RT volume can span up to 2^52 blocks, a preallocation of 2^22
blocks will be expressed as two records of 2^21 length.  We don't
opportunistically combine records when doing bmbt operations, which is
why the fsck tools have never complained about this scenario.

Offline repair is partially effective at detecting mergeable records
because I taught it to do that for the rmap and refcount btrees.  This
series enhances the free space, rmap, and refcount scrubbers to detect
mergeable records.  For the bmbt, it will flag the file as being
eligible for an optimization to shrink the size of the data structure.

The last patch in this set also enhances the rmap scrubber to detect
records that overlap incorrectly.  This check is done automatically for
non-overlapping btree types, but we have to do it separately for the
rmapbt because there are constraints on which allocation types are
allowed to overlap.

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

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmLQVPsACgkQ+H93GTRK
tOukixAAj2pzKm8jVH8BLYEw4gMU9EASsUrM4ZbKfcjRQmPfPbUd+X4KdY2C7AUt
vtHzXMfXN8DnFh8PzPGEQEkSfi8Vy1mEB8Av1/55PvronCklofrvjcBY1qPTAagt
NL1928SU+DSaKVZS49BWnLOEzLmo2GZ+6bWnLwCOLNco+JFCZV185leBZ4GKpo3e
Y9EsY1e11UEiGriGpguPHk0UK2ahP0OPnDlQGYt/Rwm7Fm1G8o1cks5/CgoNQKjn
5NTuW3ch2xAlqt/yWSWud/41tRJ5g1rrp0JE7v/D5vIargx6VxqAQa+Zur3GNi54
bgUTs3+EJdn1wrcauPBIzWjlfr0yEgL1OvWNl3Rv2WIOsYK7mPCP+D07hi4u4dGD
e6zQE5GcfUM0MHvNtYqs7HASLgAEmdikGS5FqhkOkDT3I7GvLRBF2DM5RKeIT36V
T3D4vDPNl/c6kjIKYuGYtsvkUKfh+zUBkXK9G2DxiOCJm+r1nb11OYtX01XJvFKH
sq40IAcDn4HWXTkwGKQW71yF0/CVxCCP6LHszd+vQBOTEAUgazSKOrCZ+7M5IJB4
0ReuirYWLzAwPtN5Ky0haFFmnsSlhMRmFGToaF7227SRbc3xDwmnf5OszkT81J8D
o3ewZDJ7Dq2u7S1aP9iFcTBH+G9rPvW5ewUg5gYlDdCJgGm1qo0=
=bjBW
-----END PGP SIGNATURE-----