xfs: fix online repair block reaping

These patches fix a few problems that I noticed in the code that deals
with old btree blocks after a successful repair.

First, I observed that it is possible for repair to incorrectly
invalidate and delete old btree blocks if they were crosslinked.  The
solution here is to consult the reverse mappings for each block in the
extent -- singly owned blocks are invalidated and freed, whereas for
crosslinked blocks, we merely drop the incorrect reverse mapping.

A largeish change in this patchset is moving the reaping code to a
separate file, because the code are mostly interrelated static
functions.  For now this also drops the ability to reap file blocks,
which will return when we add the bmbt repair functions.

Second, we convert the reap function to use EFIs so that we can commit
to freeing as many blocks in as few transactions as we dare.  We would
like to free as many old blocks as we can in the same transaction that
commits the new structure to the ondisk filesystem to minimize the
number of blocks that leak if the system crashes before the repair fully
completes.

The third change made in this series is to avoid tripping buffer cache
assertions if we're merely scanning the buffer cache for buffers to
invalidate, and find a non-stale buffer of the wrong length.  This is
primarily cosmetic, but makes my life easier.

The fourth change restructures the reaping code to try to process as many
blocks in one go as possible, to reduce logging traffic.

The last change switches the reaping mechanism to use per-AG bitmaps
defined in a previous patchset.  This should reduce type confusion when
reading the source code.

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

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmNJ0ikACgkQ+H93GTRK
tOscJA/+POB5z83melPiEa76qEmgY8IAEDqJsaJe+NPXF3c4zhkNcEsMzRLUv78F
fc+5lgMYO8n/efMdSsTGi3QRIA2meFALLhhVzPVkcjoKYVuYtlHzkVv4rIPLP14/
kuMM38sHk/kyJx+UYtdlzbRuPXp2Ufu03u66bwXfp2RHzzeh7gFH1F2nuLN+Rnvk
UTeqGJKcMXIVU4KXh1aM+ouK5LpuY1WvaAUESBatYkX/sTdbeMBl2McpTSyDwI7J
HmqcSbzo5PwQl2z48nlJuK5ZZEryhsX4D++hiDn6U+dXq4mCgFvgsRnBcIblkXQX
JtncftLqUEmeqLxLf+vUhVvaU3N/MA6ToyGrKfNhuTUpqF/CMJbMaJurpqjj3mi+
M8DQJwBJy4VXzGXrbk65NzFqpjrknB4ZvGfjUZQkm0OZKfSB67kUCTMD5w6lo6xN
51t8emSxsAERFEwic6Bbu/6V5nq7Sxm7nmIQjf2RZl6aBv4S3dCOnFSDrhf3Oxp+
GceK2HDsJ1JIlt036zQ9i6eR+0poUP2++6WNoNXKEL+jHE7mdgW9tD2vRO8RaELH
pXSIz1S4lcwVfB2VU0KFpyWpWUAjujlDJjeuqtkwpeWVCN3QP1Kj9p/NzX6B6CtG
GLXSCVWIHiKONqCeMeudbkocPD2lfHs9CvDqOUq5istgO2qi994=
=9dkQ
-----END PGP SIGNATURE-----