fix(migrationhelper): keep the primary key while changing its column type

[tpam28]

Summary

ChangePrimaryKeyColumnsType dropped the primary key, copied data into the new column, and added the key back. MySQL Group Replication rejects DML on tables without a primary key, so the copy failed with error 3098. The table stayed without a primary key, and the next start failed with error 1091.

Now the helper keeps the primary key the whole time:

• The key stays on the old column while it is renamed to a temp column and the data is copied.
• After the copy, one ALTER TABLE ... DROP PRIMARY KEY, ADD PRIMARY KEY (...) moves the key to the new column.
• If the table has no primary key (left by an earlier failed run), the helper adds it back before it copies data.

ChangeColumnsType keeps its behavior. Its body moved to a private changeColumnsTypeWithHook that runs a hook between the copy and the drop of the temp columns.

The only caller is core migration 20240124155129 (refs.id from varchar(255) to varchar(500)).

Does this close any open issues?

Closes #9194

Other Information

Sonarqube migration 20230927145127 drops the primary key of _tool_sonarqube_file_metrics itself, outside this helper, so it still fails on Group Replication. This PR doesn't change it.

Tests

New e2e test test/e2e/migrationhelper/change_primary_key_test.go runs against E2E_DB_URL. It covers a table with a primary key and a table without one. On MySQL it sets sql_require_primary_key = ON for the session, so MySQL rejects any statement that leaves the table without a primary key. This catches the bug without Group Replication in CI.

Results:

	this PR	main
MySQL 8.4.11	pass	fail (3750, 1091)
MySQL 8.0 with single-node Group Replication	pass	fail (3098, 1091)
PostgreSQL 14	pass	—

I also started DevLake from this branch with all Go plugins on a fresh MySQL 8.0 with Group Replication. The refs migration now passes. Without the sonarqube plugin all migrations pass and the server starts. On PostgreSQL 14 the core migrations pass.