kv: implement replicated key-level locks

[nvanbenschoten]

Related to #52768.
Related to #75456.

Ignoring intents, CockroachDB currently only supports the unreplicated lock durability. Consequently, FOR UPDATE locks are subtly best-effort; it is possible for a client to unknowingly lose a lock (violates mutual exclusion) and even still commit (violates isolation).

The best-effort nature of these locks is surprising for Serailizable transactions and a correctness hazard for Snapshot and Read Committed transactions.

We should implement the Replicated lock strength:

cockroach/pkg/kv/kvserver/concurrency/lock/locking.proto

Lines 187 to 210 in 2414bba

	// Durability represents the different durability properties of a lock acquired
	// by a transaction. Durability levels provide varying degrees of survivability,
	// often in exchange for the cost of lock acquisition.
	enum Durability {
	option (gogoproto.goproto_enum_prefix) = false;
	// Replicated locks are held on at least a quorum of Replicas in a Range.
	// They are slower to acquire and release than Unreplicated locks because
	// updating them requires both cross-node coordination and interaction with
	// durable storage. In exchange, Replicated locks provide a guarantee of
	// survivability across lease transfers, leaseholder crashes, and other
	// forms of failure events. They will remain available as long as their
	// Range remains available and they will never be lost.
	Replicated = 0;
	// Unreplicated locks are held only on a single Replica in a Range, which is
	// typically the leaseholder. Unreplicated locks are very fast to acquire
	// and release because they are held in memory or on fast local storage and
	// require no cross-node coordination to update. In exchange, Unreplicated
	// locks provide no guarantee of survivability across lease transfers or
	// leaseholder crashes. They should therefore be thought of as best-effort
	// and should not be relied upon for correctness.
	Unreplicated = 1;
	}

We should then address #100194.

Jira issue: CRDB-26577

Epic CRDB-26544

[nvanbenschoten]

The API for replicated key-level locks will look similar to the API for unreplicated key-level locks. GetRequest, ScanRequest, and ReverseScanRequest will all receive a new KeyLockingDurability lock.Durability field that lives beside their existing KeyLocking lock.Strength (rename to KeyLockingStrength?) field.