release-21.2: sql: do not collect statistics on virtual columns

[blathers-crl]

Backport 1/1 commits from #71105 on behalf of @mgartner.

/cc @cockroachdb/release

---

PR #68312 intended to update the behavior of CREATE STATISTICS to
prevent statistics collection on virtual computed columns. However, it
failed to account for multi-column statistics and for
CREATE STATISTICS statements that explicitly reference virtual
columns. This commit accounts for these two cases.

This prevents internal errors from occuring when the system tries to
collect statistics on NOT NULL virtual columns. Virtual column values
are not included in the primary index. So when the statistics
job reads the primary index to sample the virtual column, it assumes the
value is null, which violates the column's NOT NULL constraint. This
violation causes an error.

Fixes #71080

Release note (bug fix): A bug has been fixed which caused internal
errors when collecting statistics on tables with virtual computed
columns.

---

Release justification: This fixes internal errors when collecting statistics
on tables with virtual computed columns.

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues.
• 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]

for 21.2.1 (unless you think this is a release blocker?)

Do we need to backport #68312 as well, or is that already included in 21.2?

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

[mgartner]

I think this can wait for 21.2.1.

I've confirmed that #68312 is already included in the release-21.2 branch, so there is no need to backport it.

[cucaroach]

Reviewable status: complete! 2 of 0 LGTMs obtained (waiting on @mgartner)