[FLINK-39749][mysql-cdc] Support configurable string chunk key comparison mode to align with MySQL collation

[ziyanTOP]

What is the purpose of the change

Fix chunk splitting and binlog event routing issues when MySQL collation differs from Java's natural String ordering.

Java `String.compareTo()` is case-sensitive (Unicode code point order), while MySQL collations like `utf8mb4_general_ci` are case-insensitive. This mismatch causes chunk boundaries computed by Java to diverge from actual MySQL row ordering, leading to premature unbounded chunks, overlapping splits, or lost binlog events.

See FLINK-39749 for details.

Brief change log

• Introduce `ChunkKeyCompareMode` enum: `DEFAULT`, `CASE_INSENSITIVE`, `BINARY`
• `DEFAULT`: preserves existing behavior (`String.compareTo()`)
• `CASE_INSENSITIVE`: uses `String.compareToIgnoreCase()` for Java-side comparisons
• `BINARY`: injects `BINARY` keyword in SQL predicates and uses byte-level comparison in Java
• Cover all three API layers: DataStream API, Flink SQL, Pipeline YAML
• Update documentation (EN + ZH) and add test coverage

Verifying this change

This change is already covered by existing tests (`MySqlTableSourceFactoryTest`) and has been verified in a production Pipeline job (MySQL -> Paimon) with `CHAR(36)` UUID primary key and `utf8mb4_general_ci` collation.

Does this pull request potentially affect one of the following parts

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no
• The serializers: no
• The runtime per-record code paths (performance sensitive): yes (affects chunk key comparison in snapshot/binlog phases)
• Anything that affects deployment or recovery: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? yes
• If yes, how is the feature documented? docs

[lvyanquan]

We can use SHOW VARIABLES LIKE "collation_server" to query the character set in use from MySQL, avoiding the introduction of a new configuration parameter.

[ziyanTOP]

Good point, but collation_server is just the server default — the actual table or column can override it. To auto-detect properly we'd have to query information_schema.COLUMNS per table at startup, and it gets messy with composite PKs where each column might have a different collation.
So I went with explicit config for now — default keeps backward compat and won't break anyone. We can add an auto mode later: detect each table's chunk-key collation during snapshot, store it per-table in the split state, and handle them individually

mistake