release-22.1: opt: use only required columns in provided ordering for project

[DrewKimball]

Backport 1/1 commits from #86193.

/cc @cockroachdb/release

---

Project operators can only pass through their input ordering.
However, the provided ordering may have to be remapped in order to
ensure it only refers to output columns, since the Project can add
and remove columns. The Project uses its internalFDs field to
accomplish the remapping; these are constructed when the Project
is added to the memo by combining the functional dependencies of the
input and the projections.

The problem occurs when transformation rules cause the input of the
Project to "reveal" additional functional dependencies. For example,
one side of a union may be eliminated and the FDs of the remaining side
used in the result. This can cause the Project to output an ordering
that is equivalent to the required ordering according to its own FDs,
but which a parent operator cannot tell is equivalent because its FDs
were calculated before the tranformation rule fired. This can cause
panics later down the line when the provided ordering does not match
up with the required ordering.

In the following example, an exploration rule transforms the join into
two joins unioned together, one over each disjunct. After the
transformation, a normalization rule fires that removes the
t0.rowid IS NULL side because rowids are non-null. This reveals the
t1.rowid = t0.rowid FD, which later causes t0.rowid to be used in
a provided ordering rather than t1.rowid. For the reasons mentioned
above, this later causes a panic when a Project attempts to remap to
the required t1.rowid ordering.

CREATE TABLE t0 (c0 INT);
CREATE TABLE t1 (c0 INT);

SELECT * FROM t0 CROSS JOIN t1
WHERE (t0.rowid IS NULL) OR (t1.rowid IN (t0.rowid))
ORDER BY t1.rowid;

This commit prevents the panic by making Project operators remap the
input provided ordering to use columns from the required ordering
(which are a subset of the output columns). This prevents the disparity
between required and provided orderings that can cause panics down the
line. In the example given above, the t1.rowid column would be chosen
for the provided ordering because it is in the required ordering.

Fixes #85393

Release note (bug fix): fixed a vulnerability in the optimizer that could
cause a panic in rare cases when planning complex queries with ORDER BY.

Release justification: low-risk bug fix

[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 

[rytaft]

Reviewed 2 of 2 files at r1, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball)

[DrewKimball]

TFTR!