Consider allowing multiple conflicting transactions to proceed until one of them commits

[mbautin]

Suppose two transactions (e.g. snapshot isolation) are writing conflicting values to key k. Currently we detect the conflict at the provisional record write time based on priority. We abort the transaction with lower priority immediately and the transaction with higher priority is allowed to proceed. However, that transaction itself might get aborted for other reasons. If we could let transactions t1 and t2 proceed, noting the fact that they are in conflict, and whichever commits first has to first abort the other transaction, then in some scenarios we would achieve a concurrency improvement. However, we'll have to deal with this race condition: suppose t1 tries to commit, it aborts t2 and is about to update its status to "committed", but another transaction, t3, writes a provisional record for the same key in the meantime.

[bmatican]

Closing in favor of #5680
cc @robertsami @pkj415