release-23.2: opt: fix inverted index constrained scans for equality filters

[blathers-crl]

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

/cc @cockroachdb/release

---

opt: fix inverted index constrained scans for equality filters

This commit fixes a bug introduced in #101178 that allows the optimizer
to generated inverted index scans on columns that are not filtered by
the query. For example, an inverted index over the column j1 could be
scanned for a filter involving a different column, like j2 = '5'. The
bug is caused by a simple omission of code that must check that the
column in the filter is an indexed column.

Fixes #111963

There is no release note because this bug is not present in any
releases.

Release note: None

randgen: generate single-column indexes more often

This commit makes randgen more likely to generate single-column
indexes. It is motivated by the bug #111963, which surprisingly lived on
the master branch for sixth months without being detected. It's not
entirely clear why TLP or other randomized tests did not catch the bug,
which has such a simple reproduction.

One theory is that indexes tend to be multi-column and constrained scans
on multi-column inverted indexes are not commonly planned for randomly
generated queries because the set of requirements to generate the scan
are very specific: the query must hold each prefix column constant, e.g.
a=1 AND b=2 AND j='5'::JSON. The likelihood of randomly generating
such an expression may be so low that the bug was not caught.

By making 10% of indexes single-column, this bug may have been more
likely to be caught because only the inverted index column needs to be
constrained by an equality filter.

Release note: None

---

Release justification: Fixes a regression that causes incorrect
results for queries involving inverted JSON indexes.

[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 

[michae2]

Reviewed 3 of 3 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @DrewKimball, @mgartner, and @rharding6373)