kv: implement leader leases

[nvanbenschoten]

We want the properties of expiration-based leases, but without the cost of a replicated write per range every 3 seconds, and without the cost of ticking/heartbeating Raft ranges. In particular, we want to ensure the lease is functional (can process reads and replicated writes) and that it eagerly acquires leases.

From the current working design doc:

Our goal is per-range raft leadership and range leasing with quorum availability and without the cost of per-range heartbeating. Connectivity to the other voting replica stores for a range is needed to retain leadership and, by extension, leaseholdership.

See the design doc for details on how this will be accomplished, the resulting scaling behavior, and the architectural simplifications that fall out.

Subtasks:

• [x] fix Leader lease interactions in proposal buffer
• [x] make sure quiescence works with leader leases

Jira issue: CRDB-38570

Epic CRDB-37522

[blathers-crl[bot]]

cc @cockroachdb/replication

[mohanr-rubrik]

@nvanbenschoten Can the design doc be made public if the design is finalized? Just curious to see the proposed protocol