feat(schema-engine): use pk for implicit join tables on postgres

[aqrln]

Use primary key constraint rather than a unique constraint on the (A, B) pair in implicit m:n join tables on PostgreSQL.

We gate this change to PostgreSQL only because this fixes a Postgres-specific issue with logical replication, and is not that useful for other providers, while having more complicated migration path or write performance or storage implications in other databases. On Postgres this change is fairly non-intrusive (except the one time cost of rebuilding the index and having two indexes for a short period of time).

Migrate normally generates all ALTER TABLE statements after the DROP INDEX statements. To ensure the migration is safe, when we detect that a unique index is "promoted" to a primary key (in any table, not necessarily just in this case), we reorder the DROP INDEX statement after the primary key is created. Otherwise creating the primary key may fail if non-unique records are inserted in between, since Prisma Migrate doesn't use transactions by default (except on SQL Server).

Fixes: prisma/prisma#25196

[codspeed-hq]

CodSpeed Performance Report

Merging #5057 will not alter performance

_{Comparing implicit-m2m-id (b95bef8) with main (1886abc)}

Summary

✅ 11 untouched benchmarks

[github-actions]

WASM Query Engine file Size

Engine	This PR	Base branch	Diff
Postgres	2.049MiB	2.049MiB	0.000B
Postgres (gzip)	821.939KiB	821.940KiB	-1.000B
Mysql	2.013MiB	2.013MiB	0.000B
Mysql (gzip)	807.917KiB	807.917KiB	-1.000B
Sqlite	1.910MiB	1.910MiB	0.000B
Sqlite (gzip)	768.140KiB	768.139KiB	1.000B

[jkomyno]

Topological graph + explicit partial order would probably be the best course of action in the long term.
Currently, we need to manually be careful when defining the operations that impact the schema.prisma <-> SQL translation.

[jkomyno]

Nice one!