Remove support for primary indexes

[morozov]

The affected features were deprecated in #6867. See the upgrade notes for details on the end-user impact.

Improvements

As a side effect, this change provides the following:

1. Dropping a primary key constraint is now supported on all platforms.
2. Naming a primary key constraint is now supported on all platforms except for MySQL and SQLite. This is a limitation of the platforms in question.

Technical details

1. This PR only forbids passing true as the $isPrimary argument of the Index constructor but does not remove the parameter itself. Removing the parameter would require modifying code that instantiates non-PK indexes as well. Once we introduce IndexEditor, we will mark the constructor as @internal and then remove the parameter.
2. The code modified by the "Compare unquoted names to unquoted names" commit is incorrect in all DBAL versions but the corresponding issue is only reproducible on 5.0.x and only in-between the commits of this PR. The issue is that the comparison is performed between the quoted index column names (derived from the introspected PK constraint). This way, they will never match. In 4.3.x, all introspected SQLite objects are always unquoted, so the comparison works aas expected.

Closes #807
Fixes #2294
Closes #3890

[Copilot]

Pull Request Overview

This PR removes support for representing primary key constraints with the Index class, reflecting deprecated features and clarifying the end-user impact with a BC break in upgrade notes.

• Documentation now explains that primary indexes are no longer returned or considered in index management.
• Several methods related to primary key constraints have been removed or adjusted (e.g. Table::getPrimaryKey, Table::setPrimaryKey, and PostgreSQLPlatform::getDropIndexSQL).
• The upgrade notes have been updated to outline the changes and impact clearly.

Files not reviewed (19)

• src/Platforms/AbstractMySQLPlatform.php: Language not supported
• src/Platforms/AbstractPlatform.php: Language not supported
• src/Platforms/DB2Platform.php: Language not supported
• src/Platforms/Exception/UnsupportedPrimaryKeyConstraintDefinition.php: Language not supported
• src/Platforms/OraclePlatform.php: Language not supported
• src/Platforms/PostgreSQLPlatform.php: Language not supported
• src/Platforms/SQLServerPlatform.php: Language not supported
• src/Platforms/SQLitePlatform.php: Language not supported
• src/Schema/AbstractSchemaManager.php: Language not supported
• src/Schema/Comparator.php: Language not supported
• src/Schema/DB2SchemaManager.php: Language not supported
• src/Schema/Exception/InvalidIndexDefinition.php: Language not supported
• src/Schema/Index.php: Language not supported
• src/Schema/MySQLSchemaManager.php: Language not supported
• src/Schema/OracleSchemaManager.php: Language not supported
• src/Schema/PostgreSQLSchemaManager.php: Language not supported
• src/Schema/PrimaryKeyConstraint.php: Language not supported
• src/Schema/SQLServerSchemaManager.php: Language not supported
• src/Schema/SQLiteSchemaManager.php: Language not supported

[greg0ire]

Applications can deal with several platforms. Will it be clear enough which platform we are talking about, or should this method accept an AbstractPlatform argument?

[morozov]

My assumption was that the operator of the application knows which database platform a it's deployed against, but I guess the point is that a single application may use multiple platforms (e.g. MySQL for inventory and Oracle for billing). In this case, yes, having the platform as part of the message should be helpful.

We can also include the table name and constraint name in the message. The constraint name is unavailable for unnamed constraints (in fromNonClusteredConstraint()), and the table name is unavailable in getPrimaryKeyConstraintDeclarationSQL() from where this exception can be thrown, so I'll just add the platform class.