[Feature][Connector-V2] PR1: Pass sink table-options into auto-created MySQL target tables

[luxiaolong-ct]

Purpose of this pull request

Add table-options for JDBC sink auto-create flow (MySQL first delivery for #11047).

• Introduce shared table-options config in SinkConnectorCommonOptions
• Propagate options into CatalogTable in JdbcSinkFactory
• Validate per dialect; MySQL/TiDB allow engine, charset, collate
• Fail fast for unsupported JDBC dialects or unknown keys

Status — MySQL JDBC only; StarRocks/Paimon out of scope for this draft.

Does this PR introduce any user-facing change?

Yes. New optional sink config table-options (map). Applied only when schema_save_mode triggers DDL (e.g. CREATE_SCHEMA_WHEN_NOT_EXIST). Does not alter existing tables or runtime INSERT/UPSERT.

How was this patch tested?

• Unit: MysqlDialectTest, MysqlCreateTableSqlBuilderTest
• E2E: JdbcMysqlTableOptionsIT

Check list

• If any new Jar binary package adding in your PR, please add License Notice according
  New License Guide
• If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
• If necessary, please update incompatible-changes.md to describe the incompatibility caused by this PR.
• If you are contributing the connector code, please check that the following files are updated:
  1. Update plugin-mapping.properties and add new connector information in it
  2. Update the pom file of seatunnel-dist
  3. Add ci label in label-scope-conf
  4. Add e2e testcase in seatunnel-e2e
  5. Update connector plugin_config

[DanielLeens]

Thanks for working on this. I reviewed the full diff from JdbcSinkFactory down into the MySQL create-table builder and the new E2E, rather than treating this as a docs-only option addition.

What this PR fixes

• User pain: when JDBC sink auto-creates a MySQL target table, users currently have no real way to pass table-level options such as engine, charset, or collate through the sink config and get them into the generated DDL.
• Fix approach: add shared table_options, propagate them into CatalogTable.options, validate them per dialect, and let the MySQL create-table builder append those clauses to the final CREATE TABLE.
• One-line summary: this makes MySQL table-level auto-create options real on the actual DDL path instead of leaving them as unsupported config intent.

Runtime chain I checked

JDBC sink initialization
  -> JdbcSinkFactory.createSink(...) [connector-jdbc/.../JdbcSinkFactory.java:71-208]
      -> read table_options [73]
      -> put table_options into CatalogTable.options [183]
      -> load JDBC dialect [187-192]
      -> validateTableOptions(...) [193]

Dialect boundary
  -> JdbcDialect.validateTableOptions(...) [connector-jdbc/.../JdbcDialect.java:916-925]
      -> non-empty table_options fail fast by default
  -> MysqlDialect.validateTableOptions(...) [connector-jdbc/.../MysqlDialect.java:402-418]
      -> allow only engine / charset / collate

Auto-create path
  -> save-mode / catalog createTable(...)
      -> MysqlCreateTableSqlBuilder.build(...) [connector-jdbc/.../MysqlCreateTableSqlBuilder.java:138-157]
          -> ENGINE = ... [145-147]
          -> DEFAULT CHARSET = ... [148-150]
          -> COLLATE = ... [151-153]

TiDB compatibility boundary
  -> JdbcDialectLoader.load(url, compatibleMode, dialect, fieldIde)
      -> MySqlDialectFactory.create(...) [connector-jdbc/.../MySqlDialectFactory.java:44-48]
          -> still returns MysqlDialect for MySQL-family compatible modes except StarRocks

Key findings

1. The normal MySQL auto-create path really does hit this change. table_options is not only accepted syntactically; it reaches the final DDL builder.
2. The fail-fast behavior for unsupported dialects is the right safety boundary here. Unsupported JDBC dialects do not silently ignore user intent.
3. I did not find a blocking correctness issue in the current head.
4. The current docs mention MySQL / TiDB together. From the source path that is reasonable, because the sink still routes MySQL-family compatible modes through MysqlDialect; the current tests just do not add a TiDB runtime pass yet.

Test / stability note

• MysqlDialectTest covers supported keys, unknown keys, and unsupported-dialect rejection.
• MysqlCreateTableSqlBuilderTest checks that the generated DDL really contains the expected clauses.
• JdbcMysqlTableOptionsIT uses SHOW CREATE TABLE plus row-count verification, which is the right signal for this feature and does not rely on weak timing assumptions. I did not see an obvious flaky-test anti-pattern in the new test code.

My merge conclusion for the current head is: can merge.

Blocking items

• None from my side.

Suggested follow-up

• A TiDB runtime coverage pass would still be useful later, since the docs explicitly mention MySQL / TiDB together and the current verification is source-level plus MySQL E2E only.

Overall, the implementation is clean and the scope is well controlled. The option, validation boundary, DDL wiring, E2E, and EN/ZH docs are aligned on the current head.