release-22.2: sql: parallelize FK and UNIQUE constraints

[yuzefovich]

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

/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.

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

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is 

[yuzefovich]

The backport was dirty on each of the commits, but the conflicts were minor. I changed the default value for the cluster setting to false so that the feature is disabled by default. The release note text has been adjusted to mention this undocumented cluster setting.

[rharding6373]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @msirek)

[yuzefovich]

I just included the backport of a minor change from #92859 in order to preserve the history of commits.

[msirek]

Reviewable status: complete! 1 of 0 LGTMs obtained (and 1 stale)

[yuzefovich]

Holding off on merging this pending investigation in #97141.

[yuzefovich]

I'll open a new PR (#100520) that includes the backport of #98713.