concurrency: ensure releasing shared locks leads to correct pushes

[arulajmani]

When there are multiple shared locks on a key, any active waiters will push the first of the lock holders (aka the claimant). Previously, when the claimaint was finalized, we weren't recomputing the waiting state for any active waiters to push the new claimaint. As a result, in such a scenario, waiters would end up blocking indefinitely without pushing.

This is non-ideal, as it means we're not going to be running deadlock/liveness detection. Waiters would hang indefinitely if there was a deadlock/liveness issue. This patch fixes this behaviour by recomputing new waiting state in cases where a shared lock is released but the key isn't unlocked.

Epic: none

Release note: None

[cockroach-teamcity]

This change is 

[nvanbenschoten]

I patched in my review comments and also added shared locks back into TestLockTableConcurrentRequests.

This PR also motivated me to open #111596. I had wanted to introduce ignored sequence numbers into TestConcurrencyManagerBasic, but they run into the problem described in that issue. We'll eventually want to address it.

Reviewed 4 of 4 files at r1.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @arulajmani)

---

pkg/kv/kvserver/concurrency/lock_table.go line 3235 at r1 (raw file):

			// Note that if the lock that was cleared didn't belong to a transaction
			// all waiters were pushing, the call to informActiveWaiters will no-op.
			kl.informActiveWaiters()

We'll need this same logic down below in the if !isLocked branch. Done.

---

pkg/kv/kvserver/concurrency/datadriven_util_test.go line 178 at r1 (raw file):

	}
	maybeGetStr := func() lock.Strength {
		// TODO(arul): everywhere we use "strength" instead of "str" -- use

I ended up going in the other direction, using "str" everywhere for these concurrency manager tests.

[nvanbenschoten]

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)