infoschema: update raw args to make it drop correct table in RENAME TABLE

[tangenta]

What problem does this PR solve?

Issue Number: close #43714

Problem Summary:

Reproducible step:

create table test.t1 (id int primary key,a text);
insert test.t1 values(1,'334'),(4,'3443435'),(5,'fdf43t536653');
rename table test.t1 to mysql.t1;
SELECT * FROM information_schema.TABLES WHERE (TABLE_SCHEMA = 'mysql') AND (TABLE_NAME = 't1');

#43341 changes the behavior of RENAME TABLE: it takes two schema versions to complete. However, applyDiff() doesn't handle two SchemaDiffs properly. The same table is created twice in infoschema, causing the phantom described in #43714.

What is changed and how it works?

During applying schema diff, we check if the table already exists before creating a new table. Thus, we can skip the second creation.

Other alternative fixes include

• Drop the table first and then create a new table(like what CREATE TABLE with foreign key does).
  • Change job.Args at second step, so that it contains the new schema ID.
  • There are risks if we change job.Args, it is hard to guarantee all the components that relying on this work correctly.
• Check if the old table is dropped. If it is not found, skip creating the second table.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[zimulala]

LGTM

[Ivy-YinSu]

/retest-required

[zimulala]

Could we add comments for this logic？

[zimulala]

I feel that the effect of create table in apply is diff.TableID why do we update job.SchemaID?
It can make drop the created table in the first apply.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crazycs520, zimulala

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [crazycs520,zimulala]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2023-06-12 08:54:32.259405369 +0000 UTC m=+142621.714166671: ☑️ agreed by crazycs520.
• 2023-06-12 09:01:53.019202897 +0000 UTC m=+143062.473964201: ☑️ agreed by zimulala.
• 2023-06-12 10:18:56.687779941 +0000 UTC m=+147686.142541231: ✖️🔁 reset by tangenta.
• 2023-06-12 11:21:27.393271978 +0000 UTC m=+151436.848033278: ☑️ agreed by zimulala.
• 2023-06-12 11:26:47.211179873 +0000 UTC m=+151756.665941175: ☑️ agreed by crazycs520.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.5: #44594.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.1: #44595.

[tangenta]

/run-cherry-picker

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.1: #45056.