release-23.1.9-rc: invertedidx: derive geog/geom filters which enable inverted index scan

[msirek]

Backport 3/3 commits from #108954.

/cc @cockroachdb/release

---

The query normalization rules FoldEqZeroSTDistance,
FoldCmpSTDistanceLeft, FoldCmpSTDistanceRight, FoldCmpSTMaxDistanceLeft
and FoldCmpSTMaxDistanceRight replace binary comparison operations,
=, <, >, <=, >= involving the st_distance or st_maxdistance functions
with equivalent function calls which may enable inverted index scan, for
example st_dwithin, and st_dfullywithin. For non-null and non-empty
geographies and geometries, this rewrite is semantically equivalent, but
for null or empty inputs, st_distance uses three-valued boolean logic
and returns a null. st_dwithin always returns true or false, so may
return a different value when the expression is negated. For example,
the following test returns true, but should return null:

CREATE TABLE g1 (geog GEOGRAPHY);
INSERT INTO g1 VALUES (ST_GeogFromText('MULTILINESTRING EMPTY'));
SELECT ST_Distance('POINT(0 0)'::GEOGRAPHY, geog) > 1 AS predicate_result FROM g1;
  predicate_result
--------------------
         t

The solution is to move all of the logic in the above normalization
rules into geoFilterPlanner.extractInvertedFilterConditionFromLeaf,
and use the derived predicate only for the purposes of finding inverted
index scan spans. The spans will always include all rows qualified for
the original predicate, but may include additional rows. The original
filter is then applied to the results of the inverted index scan to
filter out any results with nulls or empty geographies and geometries.

Epic: none
Fixes: #103616

Release note (bug fix): This patch fixes a bug in geospatial queries,
where a query filter of the form ST_Distance(geog1, geog2) > constant,
or ST_MaxDistance(geom1, geom2) > constant, where the operator is one
of >, <, >=, <=, or a filter of the form ST_Distance(geog1, geog2, false) = 0
may mistakenly evaluate to true when one or both of the inputs is null
or an empty geography/geometry. More rows could be returned by the query
than expected.

---

xform: move st_distance rules tests from norm to xform

This commit moves the tests for the old normalization rules
FoldEqZeroSTDistance, FoldCmpSTDistanceLeft, FoldCmpSTDistanceRight,
FoldCmpSTMaxDistanceLeft and FoldCmpSTMaxDistanceRight from norm
into xform. The tests now check whether the derived filter triggers the
GenerateInvertedIndexScans rule.

Epic: none
Informs: #103616

Release note: None

---

invertedidx: move geospatial filter derivation functions out of norm

This commit moves functions previously associated with normalization
rules, but now associated with exploration-time geospatial filter
derivation out of the norm package.

Epic: none
Informs: #103616

Release note: None

Release justification: fix for incorrect results from filters using the st_distance function on null or empty geography/geometry values

[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 

[DrewKimball]

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

[msirek]

@mgartner OK to merge this one to 23.1.9-rc?

[mgartner]

Sure, let's do it.