xfs: fix various bugs in fsmap

While performing some code audits of the fsmap code, I noticed some off
by one errors in the realtime bitmap query code that provides the rt
fsmap implementation.

The first problem I found is that while the rtbitmap range query
function will constrain the starting and ending rtextent parameters to
match the actual rt volume, it does so by changing the struct passed in
by the caller.  This is a no-no, since query functions themselves are
not supposed to change the global state.

The second problem is an off-by-one error in the rtbitmap fsmap function
itself.  The fsmap record emitter function has the neat property that it
can detect gaps between the fsmap record we're about to emit and the
last one it emitted.  When this happens, it first emits an fsmap record
to fill the gap and then emits the one it was called about.

When the last block of the queried range is in use, we synthesize a
fsmap record just outside the query range, which has the effect of
emitting an "unknown owner" fsmap record for the inuse space.
Unfortunately, we don't range check the last block value, with the
result that the "unknown owner" fsmap can claim to extend beyond the end
of the rt volume!  So range check that.

The third problem is similar to the first: each fsmap backend is passed
the keys of the range to query and some scratch space.  The backend can
change anything it wants in the scratch space, but it's not supposed to
change the keys.  Unfortunately, range checking in the backend functions
/did/ change the keys, which causes subsequent backends to be called
with incorrect keys.  Fix this.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEUzaAxoMeQq6m2jMV+H93GTRKtOsFAmEVrpYACgkQ+H93GTRK
tOumsw/8DT4RC8hRv6Mpsv/L8NmK9tyBAz6KuOTYsCSTU37xN+O8y83HnAyWTI3j
iNE5SvngqPYLa/BRH8iMnudYY5YSTBiP3QoNDagc8dnJd4kFGn05GZNhFN1scQpW
BKw18XLGQ3N20yE37TOh/fzOR3OIOfwfv4ixxfkEd/LzuuwEmncSk4rPF1iPX1x2
1uXL2XiC1X85K1kIBm1h17wo4r816OqNL7njYA9ohhmyUU99XyLFbH7s9h8bDDRU
JlP/qRAlPhZtURi7TMG8z2tYp2sWxuw4wUnuFFQFyV1JY06yRXHzlAawFzj23R+o
DmEvZk8aPBtnLrvkSAY345Qd09qqgN7qIlHiP9h5IcNrAim3qiGfAq6b5vKSBo+n
SQ5U+HoONbUsX4w6qqIvZZzASVqGROtjyc2t3Ht7pCX+oKMLW70Ac8c97zjgchCK
R6MUewAumkxLGzb8wYZiyzarAVDa+UgLyP48Gr8TS5RJ5PbejjUt6Uau4O508oto
jbIj88ZyjuDhUU1rMkCBcpQnOhKafA6TyJCWoOog5px5ri/yAzG3OTpiql65OCrA
8FRhhRwSPbJLjiOhtYb5bKYK5DuH4cCstWFjEqgm2pfSWseorArpvvsLS1Eu30r0
V7Ycz4rGXhrDCzyDp2DX7qyjnyNwafSGlaoYgHsMGjlDno24++Y=
=u+r1
-----END PGP SIGNATURE-----