Always read writes from same txn epoch.

We must do this even in the event that the timestamp of a write from our
own txn gets pushed forward so txn is attempting to read earlier
timestamp. We can't have a txn intent getting pushed forward by another
txn only to have it become invisible to the current txn, which isn't yet
aware the txn commit timestamp has been pushed.

Allow non-transactional reads and writes to push intents. This is
done by generating a random priority for the non-transactional actor.
We could consider allowing priority to be set as an optional field of
RequestHeader, outside of RequestHeader.Txn for non-transactional commands.

Change push txn code to always allow pushing the timestamp forward on
txn intents where isolation level is SNAPSHOT. Since snapshot isolation
txns don't mind having their timestamp advanced, this is better overall
for system performance--readers never block on snapshot isolation txns.

Added unittests for all cases.
(In case we can construct a valid double-push scenario.) Originally, i thought we may be able to commit both transactions directly after the double-push. If that's the case, the read of txn-1 on key "b" won't include the result of txn-2. But in case the timestamp of txn-2 is early than txn-2, txn-2 will be committed after txn-1. It means the read of a SERIALIZABLE txn-2 didn't see the result of another txn-1 committed before it.

What's the criterial of restarts a SERIALIZABLE txn? always restart it when we discovers its timestamp has been pushed at commit time? I remember we will only restart a SSI txn when it contains a DeleteRange. (In your email of DeleteRange discussion) For other SSI txn, we may be able to commit it directly even after a push. Are you saying that we are going to restart all SSI txn no matter it contains a DeleteRange or not?

beside this specific example, you can see that i just try to construct a scenario with opposite push decision on different keys. And try to figure out if there is any potential issue. It is a little bit hard to confirm the correctness of this piece.

at the same, would you please share that valid double-push scenario in your mind?