[SQL] Optimization to pull expensive operations out of filters - #6818

Nice optimization. Hoisting expensive predicate operands into a preceding map lets ImplementNow see a simple field-vs-window comparison, and as a bonus lets projection pushdown drop the source columns whose only role was feeding the expensive call. The VARIANT test asserting no VARIANT-typed operator output past the hoisting map is a strong invariant to lock in.

A few things I liked:

• Dedup via EquivalenceContext.equiv on the hoisted list — BETWEEN and other patterns that duplicate operands (like the two TRANSFORM(...) copies from a range check) collapse to a single hoisted column. The nested-closure test pins that.
• Correctly skipping any subexpression that contains now() — otherwise ImplementNow would lose the temporal shape.
• Marking VARIANT casts and VARIANT_INDEX as expensive in Expensive.java — these really are runtime function calls under the hood, so the existing containsExternalFunction heuristic was missing them.
• Simplify pass before analysis normalizes the predicate shape so collect/rewrite see a predictable tree.
• Result-restoring projection is annotated IsProjection, so downstream projection pushdown can peel it off when the extra columns are unused.

Approving.

Works well on a real world program with hundreds of filters.