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.
I don't think so...that's what the priorities are for--to adjudicate between conflicting interests in a way that balances "fairness" with starvation avoidance. The reason we always push snapshot intents is that they don't mind, so the push is essentially free (and gives us better concurrency).

In your example, the pusher is type SNAPSHOT. If it has a higher priority, we want to clear out intents in its way, even if the intents are owned by a txn which will be inconvenienced by the push (i.e. a txn with type SERIALIZABLE).