release-21.1: sql: fix ColumnAccessExpr.Eval with NULL inner expression

[blathers-crl]

Backport 2/2 commits from #78423 on behalf of @mgartner.

/cc @cockroachdb/release

---

sql: fix ColumnAccessExpr.Eval with NULL inner expression

Previously, ColumnAccessExpr.Eval would panic if the
ColumnAccessExpr's inner expression evaluated to NULL, because it
attempted to cast this NULL to a DTuple. Now, if the inner
expression is NULL, ColumnAccessExpr.Eval returns NULL.

Fixes #78159

Release note (bug fix): A bug has been fixed that caused an internal
error when the inner expression of a column access expression evaluated
to NULL. For example, evaluation of the expression
(CASE WHEN b THEN ((ROW(1) AS a)) ELSE NULL END).a would error when
b is false. This bug has been present since version 19.1 or earlier.

sql: include tuple labels in types returned from typeCheckSameTypedTupleExprs

Previously, an expression that produced a tuple from several potential
values was typed as a tuple without any labels. This prevented a tuple's
column to be accessed by a label name.

For example, the expression below would result in the error "could not
identify column 'a' in record data type".

SELECT (CASE WHEN true THEN (ROW(1) AS a) ELSE (ROW(2) AS a) END).a

Now, the labels of the first tuple are used in the type of the outer
expression.

Fixes #78515

Release note (bug fix): A bug has been fixed that caused an error when
accessing a named column of a labelled tuple. The bug only occurred when
an expression could produce one of several different tuples. For
example, (CASE WHEN true THEN (ROW(1) AS a) ELSE (ROW(2) AS a) END).a
would fail to evaluate. This bug was present since version 22.1.0.
Although present in previous versions, it was impossible to encounter
due to limitations that prevented using tuples in this way.

---

Release justification: Minor 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 

[cucaroach]

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