this is the missing part of #1873 .

GC of proto.Transaction

A Transaction record can be removed if its last heartbeat is sufficiently
old (say, > 4*HeartbeatInterval) and if no intents which should be visible
remain (i.e. only if it's committed do we need to ensure that).
If no heartbeat timestamp is present,the Transaction timestamp is used instead.
Those are HLC timestamps, but on the time scales involved, this is of no concern.

The GC queue is in charge of periodically grooming the Transaction table.
It can't ever GC a successfully committed Transaction which lists possibly-
unresolved intents, though. Encountering one of those requires prior intent
resolution. It will be easiest if the queue just gives those intents to the range
to handle then asynchronously as skipped intents, which should render
the Transaction GCable in the next pass.

Any successful ResolveIntent (or collection thereof) should be followed by
an invocation of a new RPC ResolveTransaction (or overload EndTransaction
for this purpose) which updates the Transaction record, removing
the resolved intents from the list stored within the Transaction.

PushTxn

When executing against an absent on-disk record, the Transaction is
considered ABORTED if the intent's Transaction timestamp is older than
< 2*HeartbeatInterval, and no new entry is written in that case.

The choice of {2,4}*HeartbeatInterval above makes sure that PushTxn
will always find the Transaction record or decide correctly that it's ABORTED
without the need to write a new one.

successful EndTransaction

Resolve local intents right away. If that includes all intents, we can remove
the record entirely. Otherwise, add the remainder to the Transaction record and return them for asynchronous resolution.

failed EndTransaction

this fails either because of regression errors (these amount to bugs), or,
more interestingly, because the Transaction was aborted by a concurrent
writer.

Prime objective is removing the intents as soon as possible, but we can't
write on error. So we leave the Transaction record and resolve all intents
asynchronously.

Note that that can leave a Transaction in PENDING state so that it'll
likely never commit (it can be aborted due to timeout at some point) in
the case of regression errors (which amount to bugs).