MySQL and MariaDB migrations are read, so every rule works on a MySQL source

[avison9]

What it changes

cdclint reads MySQL and MariaDB migrations, so every existing rule works on a Debezium MySQL source. MySQL has no schemas: Debezium names a table database.table and a column database.table.column, so the new reader puts the database where the Postgres reader puts the schema, and the rules, include lists and topic names work unchanged.

• Which reader. The connector's class picks it (MySqlConnector, MariaDbConnector); --migrations mysql:DIR or postgres:DIR says it outright. No new flag.
• Which database. From a USE db; in the migrations, or from a connector whose database.include.list names one database (or whose table.include.list entries all start with the same one). When neither says, cdclint stops and says how to tell it; guessing would name the wrong table in every finding.
• Database lists. database.include.list and database.exclude.list (and the old whitelist/blacklist spellings) are applied before the table lists, as Debezium does. sink-table-not-captured now names the list that actually keeps the table out, with the right entry: add billing to database.include.list, not billing.invoices.
• The reader. CREATE TABLE (backticks, ENGINE options, KEY/INDEX/FULLTEXT/SPATIAL lines, LIKE, keywords glued to their column list), ALTER TABLE (ADD with FIRST/AFTER and several columns in parentheses, CHANGE, MODIFY, DROP, RENAME COLUMN, RENAME TO another database), RENAME TABLE, DROP TABLE, USE. Replica identity is left empty for MySQL tables (a Postgres setting).
• The splitter's MySQL mode. # comments, backslash escapes in strings, no dollar quoting ($ is an identifier character), and DELIMITER for routine bodies. Postgres splitting is unchanged.
• Prepared-statement DDL. MySQL has no ADD COLUMN IF NOT EXISTS, so re-runnable migrations write SET @s = (SELECT IF(<exists>, 'SELECT 1', 'ALTER TABLE t ADD c INT')); PREPARE ...; EXECUTE .... The reader applies the table statements in those strings. The IF only skips DDL whose effect is already there, and re-adding or re-dropping is a no-op in the reader, so this is the end state the migration guarantees.

Proven against a real repository

Mattermost v10.11.0 keeps the same schema as 140 MySQL and 140 Postgres migrations (golang-migrate .up.sql). A throwaway comparison, not committed, read both:

	before reading prepared-statement strings	after
tables found (MySQL / Postgres)	71 / 71	71 / 71
column differences of 610	97	12

All 12 remaining differences are on the Postgres reader's side, not this one: 9 are a glued UNIQUE(...) constraint read as a column, and 3 are columns Mattermost adds inside a PL/pgSQL DO $$ block. Both are existing Postgres-reader limitations, listed below as follow-ups.

The same run found a crash in the Postgres reader (a table name glued to a multi-line column list), fixed separately in #15; this reader has its own copy of the fix and a test for it.

Verified

• Unit tests: internal/source/mysql (every construct above in one migration set, glued multi-line names, the missing-database error), internal/sqlsplit (MySQL mode: #, backslash, versioned comment, DELIMITER $$ trigger, $ in a name). The existing Postgres split test is unchanged.
• Corpus: mysql-column-never-captured, mysql-change-column, mysql-database-not-included, mysql-diff-adds-column (the diff rule through the MySQL reader and the --base path). Honest note: this time the reader was written, with its unit tests, before these corpus entries; the expectations were still written by hand before running them, and they passed as written. Writing mysql-database-not-included's expectation is what exposed the wrong billing.invoices fix.
• Every existing corpus entry unchanged; gofmt -l . clean, go vet, go test ./... pass.
• RefuseRadar: 0 error(s), 0 warning(s), 159 info, unchanged, both detected and with postgres: given explicitly.

What was rejected

• Guessing the database when neither the migrations nor the connector name one.
• Creating a table for CREATE TABLE ... AS SELECT without a column list: its columns are the query's; left out rather than invented.
• Treating MySQL generated columns differently. Whether Debezium emits them is not something I verified, so they are read as ordinary columns.

Follow-ups found on the way (not in this PR)

1. Postgres: a glued UNIQUE(a, b) in CREATE TABLE is read as a column (9 phantom columns on Mattermost).
2. Postgres: DDL inside DO $$ ... $$ blocks is not read (the Postgres twin of the prepared-statement idiom).
3. Both readers apply every *.sql, including golang-migrate's .down.sql, which undoes each migration. Any golang-migrate repository reads wrong today.

Down migrations

Rebased after #17 merged: the MySQL reader leaves out down migrations through the same internal/migrate calls as the Postgres reader (migrate.Down in ReadFiles, migrate.Up before splitting), with TestDownMigrationsAreLeftOut (Mattermost's 000092 down file, and a goose down section).

Merging

Stacked on #14, which is stacked on #13, all rebased onto main after #15 and #17: until those merge, this PR's diff also shows their commits. The code conflicts with #13 and #14 in debezium.go and engine.go were resolved by hand in this rebase (both sides kept; #13's updated PatternLister comment kept). Merge #13, then #14, then this; each goes in without conflicts. On the three together: go test ./... passes, 33 corpus entries, RefuseRadar 0 error(s), 0 warning(s), 159 info.