xfs: fix corruption of free rt extent count

I've been noticing sporadic failures with djwong-dev with xfs/141, which
is a looping log recovery test.  The primary symptoms have been that
online fsck reports incorrect free extent counts after some number of
recovery loops.  The root cause seems to be the use of sb_frextents in
the xfs_mount for incore reservations to transactions -- if someone
calls xfs_log_sb while there's a transaction with an rtx reservation
running, the artificially low value will then get logged to disk!
If that's the /last/ time anyone logs the superblock before the log
goes down, then recovery will replay the incorrect value into the live
superblock.  Effectively, we leak the rt extents.

So, the first thing to do is to fix log recovery to recompute frextents
from the rt bitmap so that we can catch and correct ondisk metadata; and
the second fix is to create a percpu counter to track both ondisk and
incore rtextent counts, similar to how m_fdblocks relates to
sb_fdblocks.

The next thing to do after this is to fix xfs_repair to check frextents
and the rt bitmap/summary files, since it doesn't check the ondisk
values against its own observations.

v2: better comments, move the frextents recalc to the summary counter
    recalc function, dont require empty transactions to check rtbitmap
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmJTHwoACgkQ+H93GTRK
tOsjXw//XiQ9KFxmdUcYwVzkjoQeCesBtl8qb2ckiImL/hX9gG7T5cyvr99ETLFi
Ju6/AkJBU4EFYWqmGIcetYfvHPHQI8Q6jhKNq8Ec6+dLYjzxQGwKpusJZfdPBhUf
Rsky/D8ZKjmtgtvaUazOXLyjzoM5vWQUjni2opnGV66VuuVy+WfmNv/amZ6+UWV1
FZqWL30oqECKZUPt4H9bXOsc/UkI9evEFOvB3IkjMmeihua8bx1id0EnQ6jkWRPl
qVH4J4PRjaVcVK4/xIiXOSpCTAC1GX6OWSbiLt7SK77JGiVY6volzBRahE0LfA6u
UCKQckZHrJMlG0xrH8auGH/6bkB+1+O3a9HObNYcSDGUKe2etMDTjyukkkISU4Oy
qK4hMExAS3ySJW2nuwk/WTaNNYhJrHpLHDbbHeF81suYeNcix+z3ynRqOwRdvnLi
iFeDoULcz2VUPRQeRusR7RGTcpdFOIRZKxc8uPqSVtHvruHeWhn6gKZOr4mDPshR
K99WxQn1S4ZHGMvkLhr8eOusbvj9n+h15e1XQOs3SahfVB1pS2H/hCfw+PHeS3UE
vOk9paZVHhZtoB0n0VCAvDzoEEtqYXNu0GspuhiPwTZU2d/4yFiXWUOHml//Wmc7
bL/7nJ/alZ+VruYfVDBVeKXMOrQoCmcGDu6xU5uxNrZggOaucn0=
=pnLe
-----END PGP SIGNATURE-----