Lifting the discussion from #14992 (comment) into its own issue.

We currently acquire write latches for the entire left-hand side and write-hand side of a range split. As a result, splits are very disruptive as they serialize with all other requests on a range. We should explore ways to make them less disruptive.

One way to accomplish this would be to declare the split as a non-MVCC read instead of an MVCC write. In practice, this would mean acquiring a read latch at timestamp 0 instead of a write latch at the transaction's timestamp. The effect of this would be that all concurrent writes to the range would be blocked but all concurrent reads to the range would be allowed.

@bdarnell writing this up did reveal a gap in my understanding about how this all works. We do currently allow reads beneath the split timestamp to be executed concurrently with a split. What makes this safe on the RHS when at any second the RHS can be removed? I think it is because of the readOnlyCmdMu, which we hold for the duration of the read, but we're about to remove that in #28813.