storage: avoid stale read due to observed timestamp after lease change

[tbg]

Discovered in #21056 (follower reads).

The fundamental problem is that when we pick up a clock read on a node that we visit, we use this as a guarantee that the node has not served any writes at higher timestamps that we could be missing (as in, that happened causally before us). But this guarantee is broken if the node later becomes leaseholder of some range after we first visited the node (where the data was in fact causally there before our visit, but the node wasn't in charge of it and thus unaware at the time).

For example,

1. put(k on leaseholder n1), gateway choses t=1.0
2. begin; read(unrelated key on n2); gateway choses t=0.98
3. pick up observed timestamp for n2 of 0.99
4. lease of n1 expires (or gets transferred), n2 takes over
5. read(k) on leaseholder n2 misses earlier put at t=1s (outside of uncertainty window up to 0.99)

@spencerkimball suggests:

Should be fixable by moving setting the MaxTimestamp from Stores.Send to after we get call Replica.redirectOnOrAcquireLease. MaxTimestamp should be set to the greater of the observed timestamp for the node and the lease start time, bounded by Transaction.MaxTimestamp. This will of course result in more uncertainty restarts, but not many, as lease transfers are not common unless the transaction is really long-running, in which case the original Transaction.MaxTimestamp will control.