xfs: fix incorrect reserve pool calculations and reporting

Last week, I was running xfs/306 (which formats a single-AG 20MB
filesystem) with an fstests configuration that specifies a 1k blocksize
and a specially crafted log size that will consume 7/8 of the space
(17920 blocks, specifically) in that AG.  This resulted mount hanging on
the infinite loop in xfs_reserve_blocks because we overestimate the
number of blocks that xfs_mod_fdblocks will give us, and the code
retries forever.

v2: Initially, this was a single patch that fixed the calculation and
transformed the loop into a finite loop.  However, further discussion
revealed several more issues:

 * People had a hard time grokking that the "alloc_set_aside" is
   actually the amount of space we hide so that a bmbt split will always
   succeed;
 * The author didn't understand what XFS_ALLOC_AGFL_RESERVE actually
   mean or whether it was correctly calculated;
 * The "alloc_set_aside" underestimated the blocks needed to handle any
   bmap btree split;
 * Both statfs and XFS_IOC_FSCOUNTS forgot to exclude the amount of
   space used by the free space btrees on behalf of per-AG reservations,
   leading to overreporting of available space;
 * The loop control change really should have been separate.

Hence, this patchset has now grown to six patches to address each of
these issues separately.

v3: only add one helper for calculating the total fdblocks setaside and
tighten some documentation

v4: It turns out I was wrong about the purpose of alloc_set_aside, so
fix the new comments in the first patch, delete the last patch, and
leave the "btree split calculations" for another patchset.  Eliminate
the looping behavior in xfs_reserve_blocks, and fix a case where we
could race to set the pool size and thereby overfill it.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmJAl4gACgkQ+H93GTRK
tOslpxAAoc+JUUsEdyW4vXhBnaGwYlZn04FGewoLrsCZQMVyxGyifgQmI7IAmndW
4WjGGdO3hVmbBSuyFoqzLPvah7QkmL/+zJUtb2VZPX5JXz+JLph3YTAPUkr4pp9X
Hkmg9BbJZKgdRab0k+og5ytKP1dCHHTCucFA53QWtcEV4VsPQ9SGbmv5uTnETo9g
PJvtACjgXtw7VQER04PVAN87zCYnricV8EUcSkzzS5G9tTlAVK5KfhdzC4r6y8ie
RhmRcpDAUhLYgS83H/Aw8CQBo/V4x6OSLUyXELn0IaNSNOPVie7U+j2Y2uR/jGos
gSV3XmhRAHWLtRMK40RTDpBxYvqxzL0ifpfarKvcc4/VmcLERG0hJzo8d+RGbfl/
VwJ5c0t7bsPBD55Y1gfkRa6CYR5an0ADXpxjJMNRCNhc17N2VSYnckY71lWN7cL/
eGl0H8nhceDcM7wpEdoJA64UExk07dbVpDBWwwH/dyc2w3ozJlTxsROHuTcN+0Ho
h1v2z7IQSvX7Ty9G1tJ//dUje7vdDXOK12/pi7QGjWQkbS+gbLf+se/+5Zyx6CwU
xdLWf0Yos83/Xltln9N9hne7wb1QVS/xB1fBiI5PtuXVCPsonSulHYf4pD1KjP6+
AMqLFTBCl21OhfQB87ldurfysar+IsP+VN8+HP7czSza55YNtEY=
=yUBp
-----END PGP SIGNATURE-----