xfs: fix reflink inefficiencies

As Dave Chinner has complained about on IRC, there are a couple of
things about reflink that are very inefficient.  First of all, we
limited the size of all bunmapi operations to avoid flooding the log
with defer ops in the worst case, but recent changes to the defer ops
code have solved that problem, so get rid of the bunmapi length clamp.

Second, the log reservations for reflink operations are far far larger
than they need to be.  Shrink them to exactly what we need to handle
each deferred RUI and CUI log item, and no more.  Also reduce logcount
because we don't need 8 rolls per operation.  Introduce a transaction
reservation compatibility layer to avoid changing the minimum log size
calculations.

v2: better document the use of EFIs to track when refcount updates
    should be continued in a new transaction, disentangle the alternate
    log space reservation code
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmJsd9UACgkQ+H93GTRK
tOs5qg//QtIruwJRhOGM9Lrk9n5sQuzn3i2cVINZrDWU522bD0cyXC/PbtB2668y
t0FRBbnxM52EokQeZMxmJE8sFzlIZYd/zuE7JoxbnYGDzakKc+t6apV5ovbhC7pH
lT7jxrNTtjAcwAvgH9SuAKAMEiypWzXizQvq8dJpCHLdItTWoRswfJ30vPpUcasv
zBELmAceJRQD1KAm1KqEDjuci3g4mxJ41bJuK/7BOsKKWaVE63g0i9jyLeAE3zho
Y8CPeN0M7js8mWnUD7b/LrAgdU5NFwjNmPgQMcwCaCMn9EXushEYYXu6cmaVFqlX
O/rE0cis6mDZWHbqNTjn+BzVnFmtlZaW8P0tMiLQZpoOww9u9dKOQ9FibRjhB45G
mSb1Y8xDi5sIzk4GnkqX8KXRpDMPhqdDXyRiI2qp+098RH5W7uAvEFP+cUbgepRT
ssWggUGSqEePLdllWmsrsZve0hg0lYSemYo9qSrOhaNEO4ozcDH5QYQmnNjGAncI
++VBXqkuVcqVFUEpdOtHcuJrx4uiAok+aBkEeOHOmJT4gDmLIbDrGT443cdY3HKr
8kygPKP3sSYMsm7uFNkHknDY69Ql5ObqJdSZ39tyCAniXjJ7vurr4B7kdVB2IqLP
GAlV/my0FVJmIdBCHIMrsIj+O9p7+4iF5iMrXCR110poOWtqaT8=
=p1iE
-----END PGP SIGNATURE-----