kv: ensure repeat shared lock acquisition+release is not quadratic with number of locks

Shared row-level locks were recently added to support weak isolation levels. Their implementation includes subtle manipulation of data structures in the storage layer (when scanning the lock table keyspace) and in the concurrency control layer (when scanning the in-memory lock table). This manipulation takes place when locks are acquired and when they are released.

Shared locks are compatible with each other, so one transaction acquiring a shared lock should not be affected by some other transaction holding one. The meaning of "affected" can be interpreted in a few different ways.

The primary meaning is that a shared lock held by one transaction should not prevent the acquisition of another shared lock by another transaction — the two are compatible. This is an unambiguous correctness requirement and we have testing in place to verify that it is upheld.

A secondary meaning is that a shared lock held by one transaction should not slow down the acquisition of another shared lock by another transaction. This is a more nuanced meaning, and is one that we can probably never achieve perfectly. Still, it seems realistic to expect that none of these shared lock interactions have a cost that is proportional to the number of shared locks already held on a key. As such, lock acquisition and release of many shared locks should not have a quadratic complexity.

I think this is currently true of the storage half of shared locks but not the in-memory half. I might be wrong about that.

We should test it. To do so, we can create a simple kvclient-level benchmark that acquires more and more shared locks on the same key and see how it scales. If it doesn't scale linearly, we should fix that.

Jira issue: CRDB-33467

Epic CRDB-34183