release-22.1: opt: add scan constant columns to ordering if they are in the output

[DrewKimball]

Backport 1/1 commits from #87562.

/cc @cockroachdb/release

---

Previously when building the provided ordering for a constrained scan, any columns proven to be constant by the constraint were ignored. This allows the optimizer to prove that the scan can provide orderings that omit those columns. However, in the case when one of these columns is an output column and the functional dependencies do not show it as constant, an internal error will result. This happens because the provided ordering omits the constant column, but the functional dependencies cannot later be used to show that the column was optional when checking whether the required ordering is satisfied.

This commit modifies the logic to only avoid considering constrained-constant index columns to be added to the provided ordering when they are not output columns.

Fixes #83793

Release note (bug fix): fixed a bug introduced in 21.2 that could cause an internal error in rare cases when a query required a constrained index scan to return results in order.

Release justification: low-risk fix for optimizer panic

[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!