release-21.1: sql: fix apply joins when inner plans have subqueries

[yuzefovich]

Backport 1/1 commits from #66442.
Backport 1/1 commits from #67569.

Two commits are squashed.

/cc @cockroachdb/release

Release justification: fix to a bug that could lead to crashes or correctness issues.
Fix is a low risk.

---

Previously, whenever the inner plan of an apply join was executed, it
would try to refer to the results of the subqueries of the outer plan
because the way we "connect" the subqueries with their results is a bit
fragile - by having an index into subquery plans slice that lives on the
planner. This could be incorrect when the "inner" plan has its own
subqueries.

In case when the "inner" plan is referring to the "inner" subqueries,
there are two bug-scenarios:

• if the "outer" plan also contains the subqueries, then the "inner"
  plan could use the incorrect result, and the whole query silently would
  return an incorrect result too;
• if the "outer" plan has no subqueries, then a panic (converted to an
  internal error by the vectorized engine) would occur.

This commit partially mitigates the problem by detecting the scenario
when both "inner" and "outer" plans have subqueries (and returning an
unsupported error) and by updating the planner to point to the "inner"
subqueries when there are no "outer" subqueries.

Fixes: #39433.

Release note (bug fix): Correlated subqueries that couldn't be
decorrelated and that have their own subqueries are now executed
correctly when supported. Note that it is an edge case of an edge case,
so it's unlikely the users have hit this bug (it was found by the
randomized testing).

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues.
• 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.

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]

Friendly ping @RaduBerinde