[FLINK-40340] Fix schema change exception when parsing MySQL zerofill data types without unsigned keyword

[Jzjsnow]

What is the purpose of this pull request?

MySQL allows declaring numeric columns with ZEROFILL alone (e.g. INT ZEROFILL),
which implicitly implies UNSIGNED. MySqlTypeUtils previously only recognized
<TYPE> UNSIGNED ZEROFILL and threw UnsupportedOperationException for bare
<TYPE> ZEROFILL, breaking schema evolution for such tables.

This PR adds explicit <TYPE> ZEROFILL constants and mapping branches that mirror
the existing UNSIGNED ZEROFILL mappings, so ZEROFILL-only columns are converted
to the same Flink type as their UNSIGNED ZEROFILL counterparts.

Brief change log

• Add <TYPE> ZEROFILL constants for all numeric types in
  flink-connector-mysql-cdc/ flink-cdc-pipeline-connector-mysql MySqlTypeUtils:
  TINYINT, SMALLINT, MEDIUMINT, INT, INTEGER, BIGINT, REAL,
  FLOAT, DOUBLE, DOUBLE PRECISION, NUMERIC, FIXED, DECIMAL.

• Add unit tests in MySqlTypeUtilsTest covering ZEROFILL type mappings for all numeric types

Verifying this change

This change added tests and can be verified as follows:

• Added unit tests in MySqlTypeUtilsTest

Documentation

• Does this pull request introduce a new feature? (no)
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

[yuxiqian]

Nice catch! Could you please add corresponding data types into MySqlFullTypesITCase?

[lvyanquan]

Hi @Jzjsnow, just a friendly follow-up when you have a chance. Are there any updates on this? Thanks for your time!

[Jzjsnow]

Nice catch! Could you please add corresponding data types into MySqlFullTypesITCase?

Thanks for the suggestion! I have added the corresponding data types to MySqlFullTypesITCase. Here’s a clarification: even if the unsigned keyword is omitted for zerofill types in a CREATE TABLE statement in MySQL, the SHOW CREATE TABLE output automatically includes the unsigned keyword. Therefore, the full snapshot synchronization itself was successful (in MySqlFullTypesITCase).

The actual cause of the failure is that the schema change DDL was generated during the incremental phase and processed without the unsigned keyword. I have also added tests to MySQLPipelineITCase to cover this scenario of the changes.

[lvyanquan]

+1.