the NodeIDs are stored within the Transaction associated to the request.
After having stored a node, future read requests within the same transaction
can set MaxTimestamp = Timestamp in order to prevent uncertainty related
restarts.

Implementing this should considerably impact performance in the relevant case
of transaction reading a busy key from a node with a fast clock, which
otherwise would lead to repeated restarts until MaxTimestamp passes.

Building on the last commit, this implements intelligent handling of
MaxTimestamp, taking into account a prior uncertainty related restarts.
In such a case, the host is known to the Txn via its NodeID, and the
request may be carried out with Timestamp = MaxTimestamp, preventing
a further uncertainty related restart

TestUncertaintyRestarts verifies that transactional reads within the
uncertainty interval cause exactly one restart. The test runs a transaction
which attempts to read a single key, but just before that read, a future
version of that key is written directly through the MVCC layer.

Indirectly this tests that the transaction remembers the NodeID of the node
being read from correctly, at least in this simple case. Not remembering the
node would lead to thousands of transaction restarts.

This can easily be tested by disabling that code in the local sender and
running the test.

The benchmark runs N transactions back to back, each writing once to the same
key.

I've been seeing a bunch of WriteIntentError related restarts, supposedly
because cleaning up the intents happens asynchronously. This looks like it's
something to expect in such a benchmark to me.

Once Raft is in place, likely the bottleneck will be that.

notably,
- the range will forward an uncertain read error using the local node's clock,
  as per spencerkimball's comment
- added a test for that
- updated comments in all affected files to point to the proto.Transaction
  comment for details on this somewhat intricate interplay.