fix: regex simplification of anchored patterns produces wrong results

[lyne7-sc]

Which issue does this PR close?

• Closes Regex simplification of anchored patterns produces wrong results #22726.

Rationale for this change

The regex simplification rule rewrites anchored regex matches (^literal$, ^(a|b)$) into cheaper = / IN / LIKE expressions. Two bugs in that path:

1. The literal was always built as Utf8 via lit(...), so on a Utf8View / LargeUtf8 column the rewritten comparison failed at execution with Invalid comparison operation: Utf8View == Utf8.
2. A ~* (case-insensitive) anchored literal was rewritten to a case-sensitive =, silently dropping rows that differ only in case.

What changes are included in this PR?

• Build the extracted literal with string_scalar.to_expr(...) so its type follows the column type (Utf8 / LargeUtf8 / Utf8View), consistent with the existing LIKE branches.
• Rewrite ~* anchored literals to ILIKE instead of =. The existing is_safe_for_like guard ensures the literal has no % / _, so this is an exact case-insensitive match. (Anchored alternations under ~* still fall back to regex evaluation.)

Are these changes tested?

Yes. predicates.slt now covers anchored ~ / ~*, single literals and alternations, over both Utf8 and Utf8View columns. Existing regex.rs unit tests still pass.

Are there any user-facing changes?

Yes, bug fixes only

[martin-g]

Tests with negation+regex are missing (!~ and !~*).

[lyne7-sc]

added !~ and !~* coverage.

[martin-g]

Question to educate myself: How the values here are Utf8View ?
I'd expect some casting to achieve that.

[lyne7-sc]

I think it's because the config map_string_types_to_utf8view defaults to true, so a VARCHAR column is planned as Utf8View in slt

datafusion/datafusion/common/src/config.rs

Lines 292 to 295 in e1d8d46

	/// If true, string types (VARCHAR, CHAR, Text, and String) are mapped to `Utf8View` during SQL planning.
	/// If false, they are mapped to `Utf8`.
	/// Default is true.
	pub map_string_types_to_utf8view: bool, default = true

[martin-g]

How this asserts the expected result ?
Neither the optimization nor the type is asserted.
Maybe use EXPLAIN ... and assert its output instead ?!

[lyne7-sc]

sounds good to me, it makes the intent clearer. I've already added EXPLAIN assertions for all the anchored cases.