kv: introduce LockSpanSet to live alongside SpanSet and use it to declare lock spans

[arulajmani]

Background

Today, we use spanset.SpanSet to declare both latch spans and lock spans when sequencing requests. The structure of SpanSet was designed for latching, and makes sense in that context, where we have read and write latches, segmented between the global and local keyspace, and latches can be MVCC or non-MVCC.

For context, the structure of SpanSet looks like:

type SpanSet struct {
	spans           [NumSpanAccess][NumSpanScope][]Span
	allowUndeclared bool
}

type Span struct {
	roachpb.Span
	Timestamp hlc.Timestamp
}

Proposal
Lock spans make limited use of SpanSets, and as we're adding support for more types of lock strengths (see Shared locks), there is an opportunity (and requirement) to reimagine how lock spans should be represented. Specifically, instead of defining and resolving conflicts based on "reads" and "writes", we should be doing so using lock.Strength instead.

The other thing to note is that we never declare MVCC lock spans -- so the Timestamp field is always empty. We instead use the associated Request's timestamp information wherever we need it. It might also not make sense to differentiate between local and global locks as there aren't that many local locks to speak of. Given all this, we should stop using SpanSets to store lock spans. Instead, we could do something simpler like:

type LockSpanSet struct {
	spans          [lock.Strength][]roachpb.Span
	allowUndeclared bool
}

Touchpoints

• There's a few touchpoints in the concurrency_control package around tryActiveWait
• DefaultDeclareIsolatedKeys will need to correctly infer locking strength when constructing lockSpans. This is easy for read-only commands (Scan, RevScan, and Get) which already pass this information. However, for all other (write) requests that call into this function, we should be able to declare their associated lock spans with Intent locking strength.

Jira issue: CRDB-27215

Epic CRDB-26544