Include id_shop in the primary key on table psgdpr_consent_lang

[lmeyer1]

Questions	Answers
Description?	In the table psgdpr_consent_lang, the field id_shop is included in the primary key (see sql/install/psgdpr_consent_lang.sql). The Doctrine/ORM annotations must reflect this. Add id_shop in PK in annotations
Type?	bug fix
BC breaks?	no
Deprecations?	no
Fixed ticket?	Fixes PrestaShop/PrestaShop#35521
Sponsor company	Société Biblique de Genève
How to test?	Run php bin/console doctrine:schema:update --dump-sql before and after. Notice that the incorrect query concerning the PK of psgdpr_consent_lang disappears.

[boo-code]

Re-verified on dev today: the fix still applies and is still needed.

PrestaShop 9.2.0, psgdpr at dev (2.0.3), with ps_psgdpr_consent, ps_psgdpr_consent_lang and ps_psgdpr_log created from this module's own sql/install/*.sql. Only this PR's line changed between the two runs of php bin/console doctrine:schema:update --dump-sql.

Before:

ALTER TABLE ps_psgdpr_consent_lang MODIFY id_gdpr_consent INT NOT NULL;
DROP INDEX `primary` ON ps_psgdpr_consent_lang;
ALTER TABLE ps_psgdpr_consent_lang CHANGE id_gdpr_consent id_gdpr_consent INT NOT NULL, CHANGE message message VARCHAR(255) NOT NULL;
...
ALTER TABLE ps_psgdpr_consent_lang ADD PRIMARY KEY (id_gdpr_consent, id_lang);

After: the MODIFY / DROP INDEX primary / ADD PRIMARY KEY triple is gone entirely.

The failure the two-column key produces, run against MySQL 8 on a copy of the table holding one row per shop:

ALTER TABLE <copy> DROP PRIMARY KEY;
ALTER TABLE <copy> ADD PRIMARY KEY (id_gdpr_consent, id_lang);
-> ERROR 1062 (23000): Duplicate entry '1-1' for key 'PRIMARY'

Separate findings from the same dump, not covered by this PR - the mapping diverges from the install SQL in four more places, three of which also fail rather than merely differ:

ALTER TABLE ps_psgdpr_consent      CHANGE error_message error_message VARCHAR(255) NOT NULL;
ALTER TABLE ps_psgdpr_consent_lang CHANGE message message VARCHAR(255) NOT NULL;
ALTER TABLE ps_psgdpr_log          CHANGE id_guest id_guest INT NOT NULL, CHANGE client_name client_name VARCHAR(255) NOT NULL;
DROP INDEX id_customer     ON ps_psgdpr_log;
DROP INDEX idx_id_customer ON ps_psgdpr_log;

error_message and message are TEXT in sql/install/*.sql, so narrowing them to VARCHAR(255) gives ERROR 1406 (22001): Data too long for column 'message' at row 1 on a 400-character consent text (measured). id_guest and client_name are nullable there. The two psgdpr_log indexes are created by the install SQL but absent from @ORM\Table(), so the schema tool treats them as unknown and drops them - including the module's own covering index.

Worth noting for anyone fixing that part: Doctrine's text type maps to LONGTEXT, not TEXT. Without length=65535 the statement only becomes CHANGE message message LONGTEXT DEFAULT NULL - non-destructive, but still a diff.