improved Txn restart behaviour

*The NodeIDs of nodes that cause an uncertainty related restart are now stored
within the Transaction associated to the request.*
After having stored a NodeID, future read requests within the same transaction
will set MaxTimestamp = Timestamp in order to prevent uncertainty related
restarts for that node.

This should considerably impact performance in the relevant case
of a transaction reading a busy key from a node with a fast clock, which
would otherwise lead to repeated restarts until MaxTimestamp passes.

*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 verified by disabling that code in the local sender and
running the test.

I've also refactored createTestDB to return an error instead of taking a *testing.T
because once you want to reuse that code in a benchmark, you will need that.

*Added a simple txn write benchmark.*
The benchmark runs N transactions back to back, each writing once to the same
key. This has nothing to do with the uncertainty stuff (and is an isolated commit).

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.
Honestly this seems like overkill to pull out into a separate class like this when we have only one use. Plus, implementing the sort interface is pretty minimal. Just do this in data.go instead.