optbuilder: fix ambiguous column references for FK cascades

[mgartner]

This commit fixes an issue in optbuilder that caused "ambiguous column
reference" errors. This error would be produced during cascading updates
if a child table's reference column name was equal to the parent column
name concatenated with _new, and the child table had a check
constraint, computed column, or partial index predicate that referenced
the column.

For example, the following UPDATE statement would produce an error.
The expected behavior is a successful UPDATE. Notice that p_new of
the child table references p of the parent table.

CREATE TABLE parent (p INT PRIMARY KEY)

CREATE TABLE child (
  c INT PRIMARY KEY,
  p_new INT REFERENCES parent(p) ON UPDATE CASCADE,
  CHECK (p_new > 0)
)

UPDATE parent SET p = p * 10 WHERE p > 1

This issue was the result of incorrect scoping while building foreign
key cascading update expressions. A column with the same name and column
ID was added to the update expression's input scope. Because the
mutationBuilder.disambiguateColumns function is unable to disambiguate
columns with the same name and column ID, building any expression that
referenced the duplicated column would result in an error.

This commit fixes the issue by no longer duplicating columns in the
update expression's input scope. mutationBuilder.addUpdateCols now
detects the special case when the update expression is a *scopeColumn
and avoids duplicating it in the generated projection scope.

Fixes #57148

Release note (bug fix): A bug has been fix that caused an "ambiguous
column reference" error during foreign key cascading updates. This error
was incorrectly produced when the child table's reference column name
was equal to the concatenation of the parent's reference column name and
"_new", and when the child table had a CHECK constraint, computed
column, or partial index predicate expression that referenced the
column. This bug was introduce in version 20.2.

[cockroach-teamcity]

This change is 

[RaduBerinde]

Thanks for getting to the bottom of this.

Please add a TODO(radu) to onUpdateCascadeBuilder.Build (above updateExprs[i].Expr = &newValScopeCols[i]) to find a cleaner way to do this, as this requires special code in addUpdateCols.

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @RaduBerinde and @rytaft)

[mgartner]

Please add a TODO(radu) to onUpdateCascadeBuilder.Build (above updateExprs[i].Expr = &newValScopeCols[i]) to find a cleaner way to do this, as this requires special code in addUpdateCols.

Done. It's kind of a weird chicken-and-egg problem. I played around with other options, but this seemed the least invasive for now.

Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @rytaft)

[mgartner]

TFTR!

bors r=RaduBerinde

[craig]

Build failed:

• GitHub CI (Cockroach)

[mgartner]

bors r=RaduBerinde

[craig]

Build failed (retrying...):

• GitHub CI (Cockroach)

[craig]

Build succeeded:

• GitHub CI (Cockroach)