release-23.1.0: opt: fix strict UDFs with subquery arguments

[blathers-crl]

Backport 4/4 commits from #101867 on behalf of @mgartner.

/cc @cockroachdb/release

---

opt: fix strict UDFs with subquery arguments

Previously, we wrapped all strict UDFs with a CASE expression to
prevent the UDF from being invoked when any of the arguments were
NULL. This was required in order to inline strict UDFs (see #94797).

Unfortunately, wrapping the arguments in a CASE expression caused
problems when the arguments were subqueries. The subqueries would be
duplicated in the optimizer expression, one copy used in the CASE
expression and another as an argument to the UDF`, with each copy
containing the same table and column IDs. Normalization rules could then
transform these subqueries into apply-joins that would have intersecting
columns in their left and right children. This caused optimizer
assertion failures in debug builds and could cause incorrect results in
release builds.

This commit implements a temporary fix which removes the synthesized
CASE expression entirely. The logic for returning NULL immediately
when a strict UDF is invoked with a NULL argument has been added back
into planner.EvalRoutineExpr, and strict UDFs are not longer inlined.

We should be able to inline strict UDFs by adding the CASE expression
during the InlineUDF normalization rule, as long as the arguments are
not complex expressions (e.g., only variables, constants, or
placeholders). This is left for a future commit.

Fixes #101516

Release note (bug fix): A bug has been fixed that could cause incorrect
results for queries invoking STRICT user-defined functions. This bug
was only present in pre-release versions of 23.1.

opt: add strict field to UDF expression format

Release note: None

opt: simplify description of ExprFmtFlags

The description of ExprFmtFlags has been simplified. It previously
contained a very detailed description of bitmasks and iota, which
probably isn't warranted because it is such a common pattern in the
codebase.

opt: inline strict UDFs

This commit inlines strict UDFs by wrapping the generated subquery
expression with a CASE expression. The CASE expression results in
NULL if any of the arguments of the UDF are NULL.

Note that even though the subquery is wrapped in a CASE expression, it
may still be evaluated due to the fact that non-correlated subqueries
are eagerly evaluated, see #20298. This should be fine because these
inlined UDFs shouldn't have side-effects - we don't inline volatile
UDFs.

Release note: None

---

Release justification: Fixes a UDF regression.

[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 5 of 5 files at r1, 3 of 3 files at r2, 1 of 1 files at r3, 2 of 2 files at r4, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball, @mgartner, @msirek, and @rharding6373)