Tracking issue for bounded staleness reads, as outlined in #66020.

The tracking issue is split into three stages:

• Stage 1 - single-scan, single-range queries
• Stage 2 - single-scan, multi-range queries
• Stage 3 - multi-scan, multi-range queries

Stage 1:

• kv: introduce QueryResolvedTimestamp request #67549
• kv: introduce bounded staleness BatchRequest Header fields #67551
• kv: implement bounded staleness server-side negotiation fast-path #67552
• kv: implement Txn.NegotiateAndSend #67553
• sql: implement bounded staleness builtin functions #67555
• sql: plumb min_timestamp_bound to TableReader #67556
• sql/opt: check query plan compatibility for bounded staleness reads #67558
• sql/kv: block queries with more than productionKVBatchSize batches from being serviced by bounded staleness #69063
• kv: use deadline as MaxTimestamp for bound staleness reads #69343
• sql: version gate bounded staleness read functions #69347
• txn_external_test: add test for bounded staleness reads negotiates and fixes the txn timestamp on resume #69386

Stage 2:

• kv: only scan separated intents span for QueryResolvedTimestamp requests #69717
• kv: implement BoundedStalenessNegotiator #67554

Stage 3:

• sql/opt: implement + plan explicit timestamp negotiation operator #67559

Epic CRDB-2527

Jira issue: CRDB-8608