kv: compatible requests should be released when a request drops out of lock wait queue

[arulajmani]

Describe the problem

Consider the following construction:

key A: 
- [holder: (req1: Shared, txn1)]
- wait queue: [(req2: Exclusive, txn2), (req3: Shared, txn3), (req4: Shared txn4)] 

If the exclusive locking request, req2, drops out of the wait queue (say it's session gets killed or whatever), the shared locking requests (req3 and req4) no longer need to wait -- they're compatible with the lock holder, and the request they were waiting on (req2) has dropped out. They should be allowed to proceed. This doesn't happen currently.

Jira issue: CRDB-31788

[nvanbenschoten]

The two pieces of logic that may be related to this are:

cockroach/pkg/kv/kvserver/concurrency/lock_table.go

Lines 3410 to 3417 in 695eaf6

	if !kl.isLocked() && doneRemoval {
	// The first request in the queuedLockingRequests should always be an
	// inactive, transactional locking request if the lock isn't held. That may
	// no longer be true if the guy we removed above was serving this purpose;
	// the call to maybeReleaseCompatibleLockingRequests should fix that. And if
	// it wasn't serving that purpose, it'll be a no-op.
	kl.maybeReleaseCompatibleLockingRequests()
	}

cockroach/pkg/kv/kvserver/concurrency/lock_table_waiter.go

Lines 354 to 371 in 695eaf6

	// If the request is conflicting with a held lock then it pushes its
	// holder synchronously - there is no way it will be able to proceed
	// until the lock's transaction undergoes a state transition (either
	// completing or being pushed) and then updates the lock's state
	// through intent resolution. The request has a dependency on the
	// entire conflicting transaction.
	//
	// However, if the request is conflicting with another request (that has
	// claimed the lock, but not yet acquired it) then it pushes the
	// claimant transaction asynchronously while continuing to listen to
	// state transition in the lockTable. This allows the request to cancel
	// its push if the conflicting claimant transaction exits the lock
	// wait-queue without leaving behind a lock. In this case, the request
	// has a dependency on the conflicting request but not necessarily the
	// entire conflicting transaction.
	if timerWaitingState.held {
	return w.pushLockTxn(ctx, req, timerWaitingState)
	}