collect NodeIDs for ReadWithinUncertainty restarts

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.
no Txn restarts for known "certain" hosts

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
add test for uncertainty restart behaviour

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.
Simple transaction benchmark

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.
address @spencerkimball's feedback

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.
Merge pull request #221 from tschottdorf/certainty

improved Txn restart behaviour
Move proto.Transaction to a separation between Key and ID.

Previously, there were two problems involved with concatenating Key & ID.

1. For KeyMin (""), the resulting concatenation wouldn't be directed to
   the first range, but to the range which encompassed the random UUID!

2. Appending the UUID would direct to the incorrect range in cases where
   the range ended before the first character of the UUID. For example.
   For a txn with key "a" and UUID "cccc-..." in range "a"-"b", the
   resulting txn key would be "acccc-...", which would actually end up
   going to the wrong range.
Weirdness with submodule.
Merge pull request #239 from cockroachdb/spencerkimball/txn-keys

Move proto.Transaction to a separation between Key and ID.
Add counter support to REST Explorer
replace docker deployment image

now based on jessie, and not using static linking and busybox any more.
getting the tests statically linked seemed more of a hassle now that we are
on Go 1.4, and it looked hacky before.

you can still build a static cockroach binary via `make STATIC=1 build`.
Merge pull request #241 from tschottdorf/deployimg

replace docker deployment image
put path in const
fix merge conflicts
remove diff marker
Merge pull request #240 from cockroachdb/andybons/counter

Add counter support to REST Explorer
mention rest explorer; update outdated comment
add -linearizable flag

when the -linearizable flag is set, the coordinator receiving the
EndTransaction request will make a note of the local wall time
before dispatching the request further, reexamining the local
clock and txn commit timestamp when the call completes successfully.

if either MaxOffset ns were spent between those two events, or
the transaction's commit timestamp is MaxOffset behind the
local clock after the EndTransaction call has been carried
out successfully, control is returned to the client immediately.
Otherwise, the smaller of the two durations described above
is waited before returning control.

This ensures that at the point of returning control, all nodes
in the system are ahead of the commit timestamp in the transaction.
address @spencerkimball's feedback
Merge pull request #244 from tschottdorf/linflag

add -linearizable flag