fix: prune statistics only through casts that keep order - #26982

Which issue does this PR close?

• Closes Parquet pruning drops rows for CAST(int AS BOOLEAN) and CAST(int AS BYTEA) predicates #26981.
• Related to Incorrect Parquet pruning for timestamp-to-time casts across midnight #26451, the same cause for timestamp → time (fixed on its own by fix: avoid pruning timestamp-to-time casts #26452).

Rationale for this change

Parquet statistics pruning can drop row groups that contain matching rows when the predicate casts the column. With i in (-1, 0, 1, 255, 256) and naive timestamps ts at 00:00, 01:00, 02:30, 02:45 and 03:00 on 2024-03-10, all in one row group:

Pruning casts the min/max statistics and compares them with the literal, which is only correct when the cast keeps the order of the values. Pruning decides that with its own check: any cast is allowed unless exactly one side is a string. So int → boolean, int → binary (little-endian bytes) and named-timezone timestamp → date all pass, although none of them keep order.

The last row is new with arrow 60.1.0 (#26867). A naive timestamp compared with a named timezone is read as a local time, and arrow now moves a local time that a transition skips forward instead of rejecting it: 02:30, which New York skipped, becomes 07:30 UTC, after 03:00 (07:00 UTC). When such a value is the minimum of a row group, the cast bounds are inverted and the query fails with Internal error: Interval's lower bound ... is greater than the upper bound.

Sort elimination already asks the same question through is_order_preserving_cast. The two checks disagree in both directions: pruning accepts the casts above, and is_order_preserving_cast rejects casts that do keep order and that pruning relies on today (integer ↔ date/timestamp/duration, string and binary re-encodings, date → timestamp with a timezone). Arrow 60.1.0 also made one of its own entries wrong: a named-timezone timestamp → Date64 now takes the local date, as Date32 does, so a sort on that cast can be removed although the output is out of order.

What changes are included in this PR?

1. is_order_preserving_cast (now public in datafusion_physical_expr::expressions) accepts the casts that keep order and that only pruning knew about:
   • string ↔ string and binary ↔ binary re-encodings (including FixedSizeBinary)
   • numbers ↔ temporal types stored as a count (date, timestamp, time, duration)
   • Date32 → timestamp with any timezone (a skipped midnight moves forward by at most a day, so it never passes the next one), and Date64 → timestamp with a fixed offset
   • Time64 → Time32 and Time64(µs) → Time64(ns), which Arrow 60.1.0 checks for overflow
2. It rejects named-timezone timestamp → Date64, as it already did for Date32.
3. Pruning (verify_support_type_for_prune) asks is_order_preserving_cast instead of its own string check.
4. A test that checks is_order_preserving_cast against the strict cast that CastExpr runs (ColumnarValue::cast_to): every pair it accepts must keep the order of sample values that convert. The samples include values around midnight, a DST gap and overlap, a timezone that moved the date backwards, and a day that Pacific/Apia skipped. A positive control asserts the samples expose the casts the rule rejects.

Pruning keeps every other cast it used before (compared over all castable pairs of the numeric, string, binary and temporal types) and stops using:

What is the testing strategy for this PR?

• test_order_preserving_cast_matches_cast_kernel (physical-expr): checks the rule against the strict cast, with a positive control. Making named-timezone timestamp → date return true fails it with 562129259 -> 1987-10-25, but 562129260 -> 1987-10-24.
• row_group_predicate_cast_must_preserve_order (pruning): casts that must not prune and casts that must keep pruning, for both CAST and TRY_CAST.
• push_down_filter_parquet.slt: the three queries above against an in-memory table and Parquet, plus an EXPLAIN showing that the same timestamp comparison under a fixed-offset session timezone still prunes.
• cast.slt: the sort on arrow_cast(i, 'Timestamp(Second, None)') is removed when the input is ordered by i (EXPLAIN and the row order), and the sort on a named-timezone timestamp cast to Date64 is kept.
• The new pruning unit test cases and Parquet queries fail with the old pruning check. The Date64 sort case and the New York Parquet query return wrong results on main.
• bloom_filter_pruning_error_retains_row_group_without_match relied on the int → FixedSizeBinary cast failing at evaluation. Pruning now rejects that cast up front, so the test compares c1 with CAST('abc' AS Int32) instead, which still fails at evaluation.

Are there any user-facing changes?

• Queries that filter Parquet through the casts in the table above return the correct rows; those predicates no longer prune row groups. With a named session timezone, comparing a naive timestamp column with a timezone-aware timestamp no longer prunes; with a fixed offset it still does.
• Sort elimination treats the newly accepted casts as order-preserving under CAST (not TRY_CAST), so a sort on, for example, CAST(int_col AS TIMESTAMP) over input ordered by int_col can be removed. A sort on a named-timezone timestamp cast to Date64 is no longer removed.
• New public function datafusion_physical_expr::expressions::is_order_preserving_cast (addition only).