Backport 1/1 commits from #92859.
Backport 3/3 commits from #96123.
Backport 1/1 commits from #98713.

/cc @cockroachdb/release

rowcontainer: support concurrent reads and some cleanup

This commit refactors the row container infrastructure in order to make
it possible to read from a single container concurrently (via separate
iterators). It required moving some of the scratch space from the
container directly into the iterators (so that the iterators don't share
anything between each other) as well as making a similar adjustment to
the pebbleMapIterator. As a result, it is now possible to safely
concurrently iterate over all types of row containers; however, the
iterators need to be created and closed under mutex protection (which
seems like an acceptable limitation). This commit also makes a minor
change to make the container a named parameter inside of the iterator
(which makes it easier to see when an iterator is touching the
container).

The ability to read from the same row container (after all rows have
been added to it) concurrently will be utilized by the follow-up commit
in order to support validation of multiple FK and UNIQUE checks in
parallel.

Additionally, this commit improves RowIterator interface a bit by
renaming Row to EncRow (since the method returns EncDatumRows) and
introducing a new Row implementation which returns tree.Datums. The
new method is now utilized in the sql.rowContainerIterator which
removes some of the unnecessary conversions between different row types.

Release note: None

sql: miscellaneous cleanup and improvement

This commit performs a bunch of minor cleanups and improvements in
preparation for the follow-up commit, in which we parallelize the
execution of post-query checks. The main rationale for changes in this
commit is making it easier to reason about concurrency-safety of
DistSQL infra.

The following changes are made:

• remove unused receiver from FinalizePlan and
  finalizePlanWithRowCount methods
• remove an unused parameter from getPlanDistribution
• remove the reference to planner from getPlanDistribution in favor
  of passing a single boolean
• refactor resetEvalCtx to make it concurrency-safe by extracting out
  the modification of extraTxnState into resetPlanner
• refactor how topLevelQueryStats are aggregated across all parts of
  the stmt (i.e. across the main query, subqueries, and postqueries) to
  make it easier to introduce concurrency-safety to it in a follow-up
• set planFlagVectorized only on the main query setup and explicitly
  propagate whether the flow is vectorized into saveFlows
• fix a couple of typos in comments.

Release note: None

sql: parallelize FK and UNIQUE constraints

This commit makes it so that we parallelize the execution of multiple
"check plans" (which include FOREIGN KEY and UNIQUE constraint checks
that run as "postqueries"). The main idea is that we use the LeafTxns
(derived from the RootTxn that was used for the main mutation query) and
execute each check in a separate task. As a result, the checks should be
completed faster, especially so in multi-region environments.

This required introduction of mutex-protection for several
planning-infra-related objects:

• saveFlows function that populates miscellaneous info, needed for the
  stmt bundle
• associateNodeWithComponents function that creates a mapping from
  planNodes to DistSQL processors, needed for different EXPLAIN variants
• topLevelQueryStats.add function that aggregates some execution stats
  across all "queries" of a stmt.

Additionally, this commit also needed to make scanBufferNodes safe for
concurrent use. The way this works is that in the main query we have
bufferNode which has already accumulated some rows into a row
container. That row container can be read from concurrently as long as
the separate iterators are created (the creation and the closure must be
mutex-protected though).

All of these things are synchronized via a single "global" mutex. We
could have introduced a separate mutex for each of these things, but
a single one seems acceptable given that these operations should be
pretty quick and occur at different points throughout the checks'
execution.

Fixes: #95184.

Release note (performance improvement): The execution of multiple
FOREIGN KEY and UNIQUE constraint checks can be parallelized in some
cases. As a result, these checks can be completed faster, especially
so in multi-region environments where the checks require cross-region
reads. The feature is enabled by default on 23.1 release, and in order
to enable it on 22.2 one must change the private
sql.distsql.parallelize_checks.enabled cluster setting to true.

sql,kv: bubble up retry errors when creating leaf transactions

Previously, if we detected that the transaction was aborted when
trying to construct leaf transaction state, we would handle the retry
error instead of bubbling it up to the caller. When a transaction is
aborted, the TransactionRetryWithProtoRefreshError carries with it a
new transaction that should be used for subsequent attempts. Handling
the retry error entailed swapping out the old TxnCoordSender with a
new one -- one that is associated with this new transaction.

This is bug prone when trying to create multiple leaf transactions in
parallel if the root has been aborted. We would expect the first leaf
transaction to handle the error and all subsequent leaf transactions to
point to the new transaction, as the TxnCoordSender has been swapped
out. This wasn't an issue before as we never really created multiple
leaf transactions in parallel. This recently change in
0f4b431, which started parallelizing FK
and uniqueness checks. With this change, we could see FK or uniqueness
violations when in fact the transaction needed to be retried.

This patch fixes the issue described above by not handling the retry
error when creating leaf transactions. Instead, we expect the
ConnExecutor to retry the entire transaction and prepare it for another
iteration.

Fixes #97141

Epic: none

Release note: None

Release justification: low-risk high-impact performance improvement disabled by default.