schemastore: incorrect old table metadata in single-table RENAME events

[lidezhu]

What did you do?

When SchemaStore processes a single-table RENAME TABLE DDL, the snapshot before the DDL commit TS may already contain the post-rename table metadata.

This behavior can occur after TiDB PR pingcap/tidb#43341.

SchemaStore already recovers the correct old schema and table names from sources such as:

• Job.InvolvingSchemaInfo
• RenameTableArgs
• The original DDL query

However, it only rebuilds PersistedDDLEvent.Query and does not update:

• ExtraSchemaID
• ExtraSchemaName
• ExtraTableName

buildDDLEventForRenameTable later treats the Extra* fields as the old table identity. Incorrect values can therefore affect:

• Filter evaluation for the old table
• BlockedTableNames
• TableNameChange.DropName
• Cross-schema rename detection
• UpdatedSchemas

For a same-schema rename, DropName and AddName may both contain the new table name, leaving the old name in the table-name store.

For a cross-schema rename, the old table may be evaluated using the new schema, resulting in incorrect filter behavior or missing schema update notifications.

Given:

RENAME TABLE source_db.t1 TO target_db.t1;

If the snapshot already contains target_db.t1, the persisted event may incorrectly contain:

ExtraSchemaID:   target_db ID
ExtraSchemaName: target_db
ExtraTableName:  t1

even though the rebuilt query is correct:

RENAME TABLE `source_db`.`t1` TO `target_db`.`t1`;

This makes the query and structured event metadata inconsistent.

What did you expect to see?

After recovering the old table identity, SchemaStore should update both the query and the structured metadata:

ExtraSchemaID: source_db ID
ExtraSchemaName: source_db
ExtraTableName: t1

The implementation should also support older TiDB versions where RenameTableArgs.OldSchemaName is unavailable by resolving the schema through RenameTableArgs.OldSchemaID.

What did you see instead?

As described above.

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):

(paste TiKV version here)

TiCDC version (execute cdc version):

(paste TiCDC version here)