Disable FK checks during Migrator::dropTables

[dereuromark]

Problem

On MySQL, Migrator::dropTables() (called during test-suite rebuilds when shouldDropTables() returns true) can fail with error 3730:

SQLSTATE[HY000]: General error: 3730 Cannot drop table 'X' referenced by
a foreign key constraint 'fk_name' on table 'Y'.
Query: DROP TABLE \`X\`

ConnectionHelper::dropTables() drops each table's outgoing FKs first and then drops the tables. With complex schemas (many cross-referencing FKs across plugins, unified-mode ledgers, and migrations that add/drop FKs in non-trivial patterns) the drop pass can still hit an ordering MySQL refuses.

This showed up in a project with ~80 migrations and ~15 FK-linked tables: after clearing the ledger to force a rebuild, Migrator::dropTables bombed on DROP TABLE bank_transactions because a FK on rent_payments pointing at it hadn't been fully resolved by the drop-constraints pass.

Projects work around this by dropping tables by hand inside $connection->disableConstraints(...) in their tests/bootstrap.php — exactly what this PR moves upstream.

Fix

Wrap $this->helper->dropTables(...) in $connection->disableConstraints(...) so MySQL doesn't enforce FK checks during the bulk drop. Drop order becomes irrelevant.

No behaviour change on SQLite or Postgres — they handle the drop order without help.

Test

Adds a MySQL-only regression test (testDropTablesHandlesCrossTableForeignKeys) that creates three tables with cascading FK references and calls dropTables directly. Skipped on SQLite/Postgres because they don't block on this pattern.

Notes

Tagged as draft while folks sanity-check the approach and the minimal test. Happy to iterate on naming / add more coverage if wanted.

[LordSimal]

I usually just drop the whole database as i dont need to keep other non related tables.

[dereuromark]

Thats usually much slower I imagine.
But yes, that project was not using Transaction strategy yet. With it, this problem would be void anyway.

Current workaround is quite ugly:

$migrationSets = [
    [],
    ['plugin' => 'Queue'],
    ['plugin' => 'DatabaseLog'],
    ['plugin' => 'Tools'],
];

// The upstream test migrator still only treats legacy `phinxlog` tables as
// migration metadata when it decides to rebuild. In unified-mode setups like
// this app, partial runs can leave real tables and the `cake_migrations` ledger
// out of sync in either direction. Reusing that state makes bootstrap flaky.
//
// Reset the shared `db_test` schema unconditionally and replay migrations from
// scratch. This is slower, but deterministic, and the repo already documents
// that PHPUnit here must run serially through ddev.
$connection = ConnectionManager::get('test');
$tables = $connection->getSchemaCollection()->listTables();
$dropTables = array_values(array_filter($tables, static function (string $table): bool {
    return $table !== 'cake_migrations' && !str_contains($table, 'phinxlog');
}));

if ($dropTables !== []) {
    $connection->disableConstraints(function ($connection) use ($dropTables): void {
        foreach ($dropTables as $table) {
            $quotedTable = '`' . str_replace('`', '``', $table) . '`';
            $connection->execute("DROP TABLE IF EXISTS {$quotedTable}");
        }
    });
}
if (in_array('cake_migrations', $tables, true)) {
    ConnectionHelper::truncateTables('test', ['cake_migrations']);
}

(new Migrator())->runMany($migrationSets);

[dereuromark]

Switching to transaction :)