It was observed in #82045 that there is a ~20% slowdown in the existing, typical read path when using an iterator stack that supports range keys, even in the case when there are no range keys to iterate over.

We'll want to claw back some / all of this slowdown.

HasPointAndRange() has also been seen to be a significant contributor, and should be optimized. Related to #83801.

Once this is done, we should optimize and benchmark the following performance-critical paths again, comparing them with 22.1:

• MVCCScan
• MVCCGet
• ComputeStats
• MVCCExportToSST
• CatchUpIterator.CatchUpScan

Jira issue: CRDB-16511

Epic CRDB-2624