kv: PUSH_TIMESTAMP with sufficient priority can starve transaction commit

In cases where one class of txns has sufficient priority to repeatedly push the intent of another class of txn, the lower priority transactions can be starved from committing. When the low-priority txns start to commit, they will notice that they have had their write timestamp pushed. They will refresh, which may take 10-100ms. By the time this completes, they may have been pushed again so they still won't be able to commit. Eventually this retry loop will bottom out and hit `maxTxnRefreshAttempts`, and the retry errors will be thrown back to the client.

I don't think this form of starvation is desirable or the intended behavior of transaction priorities. Instead, a higher-priority transaction should only be able to push the timestamp of a lower-priority transaction up to the point that the lower-priority transaction starts to commit. After that point, it should be allowed to refresh and then commit.

To resolve this, we'll want to introduce a "committing" state on the transaction record to indicate to pushers that they should wait for the commit to complete.

Jira issue: CRDB-23409

gz#19331