fix(migration): accept ITable from getTable() in addMailboxKey

[ChristophWurst]

OCP's ISchemaWrapper::getTable() now returns OCP\DB\Schema\ITable instead of Doctrine\DBAL\Schema\Table on newer server versions. Widen the addMailboxKey() parameter types to Table|ITable so the migration works on both, and suppress the not-yet-vendored ITable stub in psalm.

Assisted-by: Claude:claude-opus-4-8

Ref nextcloud/server#63013

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI

[ChristophWurst]

/backport to stable5.11

[ChristophWurst]

/backport to stable5.10

[ChristophWurst]

There are more changes necessary to make Psalm happy, but there are also legit gaps.

1. There is no replacement to enumerate all foreign keys:

   mail/lib/Migration/Version1130Date20220412111833.php

   Line 116 in 1968041

   $fks = $attachmentsTable->getForeignKeys();

2. ModifyColumn changed in a breaking way. It's not possible to be compatible with 34 and 35 at the same time:

   mail/lib/Migration/Version1130Date20220412111833.php

   Lines 129 to 131 in 1968041

   	$recipientsTable->modifyColumn('id', [
   	'type' => Type::getType(Types::BIGINT),
   	]);

[CarlSchwan]

There are more changes necessary to make Psalm happy, but there are also legit gaps.

1. There is no replacement to enumerate all foreign keys: https://github.com/nextcloud/mail/blob/1968041ebcbd120bfce97be65d40fe636428252b/lib/Migration/Version1130Date20220412111833.php#L116

This should still work, since getForeignKeys is not implemented in Table, it's forwarding the method call to the DBAL Table via the __call in OC\DB\Schema\Table

2. ModifyColumn changed in a breaking way. It's not possible to be compatible with 34 and 35 at the same time: https://github.com/nextcloud/mail/blob/1968041ebcbd120bfce97be65d40fe636428252b/lib/Migration/Version1130Date20220412111833.php#L129-L131

Same, modifyColumn in OCP\DB\Schema, has some more strict type hints but at runtime this should still work as it is just forwarding the arguments.

[CarlSchwan]

Looking at the latest psalm issues, I probably went to far for requiring non empty lowercase string for index. I will change that

[CarlSchwan]

Last psalm issue seems to be a false positive from psalm

[kesselb]

Would be nice to also expose spansColumns because it ignores the order.

As hardening we should array diff expected and actual columns and test for an empty array.

[ChristophWurst]

But the other matters. An index on [a,b] is very different from [b,a].

For this specific case we only need to catch the condition where the ordering is [account_id, name], right?