Make Drupal\Core\Database\Database type strict and PHPStan L10 compliant

This is not PHPStan level 0... it's PHPStan level 10. If you test locally the patch on the single core/lib/Drupal/Core/Database/Database.php file with PHPStan, and set the level to 10, it will pass.

I know it's a little bit futuristic but here I am exploring.

Wrt #4, on higher levels than what we have now PHPStan checks validity of the array keys being used in code against the array shape. Without @phpstan-type defined on the class level as an 'alias' of the array shape, we'd have to enter the full array shape every time it is used (16 times in this class). Readability would get definitely worse as well as the risk of errors (if you start using a new array key, you'd have to change all the instances).

There's interest in using @phpstan-type, see https://git.drupalcode.org/project/drupal/-/merge_requests/10809#note_51..., but probably not yet enough focus, see https://www.drupal.org/project/drupal/issues/3497431#comment-16102077 and https://www.drupal.org/project/drupal/issues/3082239#comment-15153451 (later comments)

BTW, such long array shapes probably hint at the opportunity to use value objects instead. I opened #3533038: Introduce a ConnectionParameters value object to store database connection parameters.

1. Removed from SettingTest:testDatabaseInfoInitialization() some test cases that were still based on db connection logic that was removed in #3294695: Drupal 8 BC for database driver namespace fails for replicas.
2. Made keys in array shapes have quotes so to improve readibility
3. Addressed @longwave's feedback

No - database drivers in sub-namespaces of Drupal\Driver\Database are long gone, and in fact those test cases should have been removed when the logic was. Better late than never.

bot fluke

I think we have to confirm here that contrib db drivers are not affected - it's not like there's many and @mondrake maintains at least 1 of them :)

• The Microsoft SQL Server driver https://www.drupal.org/project/sqlsrv has a stable version Drupal 11 compatible, so maybe it's worth asking the maintainer there.
• The Oracle driver https://www.drupal.org/project/oracle has not had commits for the last 6 years, and a quick browse of the issue queue tells us it is no longer working since Drupal 9.4. I'd say it would have bigger problems than the issue here.
• I have archived DruDbal https://github.com/mondrake/drudbal, so I am no longer in that bunch :)

@final on an abstract class? That's a bit of an oxymoron right?

Indeed, and has been so since day 1, 15 years ago, given the phpdoc said

 * This class is uninstantiatable and un-extendable. It acts to encapsulate
 * all control and shepherding of database connections into a single location
 * without the use of globals.

and all its properties and methods are static. To me, this means that the class is actually final static. Classes cannot be defined static in PHP though, but a final class could have a constructor that throws an exception in case of instantiation attempt. I'd be all for doing that, but would rather defer it to a separate issue to avoid delaying this one further (I saw heated debate on use of final).

Filed #3577786: Would tightening of Drupal\Core\Database\Database in #3532930 cause problems? in MS SQL module's issue queue.

#19 yeah... can we limit to string|int or we need to support any scalar string|int|float|bool? Having database keys/targets as floats or bools would sound a bit extreme to me.

Also, shall we just limit to the $key and $target parameters of the methods?

Done #21. Will try to add a couple of deprecations tests when I win my current laziness...

Added one deprecation test (could not win laziness to do a couple, so we came to a draw and added one)

On the Database class I could revert the doc changes. On the Connection and Log classes, apparently PHPStan on higher levels matches the native type of the parameters passed within Database to the methods called there, to the phpdoc types defined in the classes, as they don't have native type signature. Since now in Database key and target are natively typed string|int, that does not match and we get this error:

 ------ -------------------------------------------------------------------------------------------------------------------- 
  Line   Database.php                                                                                                        
 ------ -------------------------------------------------------------------------------------------------------------------- 
  512    Parameter #1 $target of method Drupal\Core\Database\Connection::setTarget() expects string|null, int|string given.  
         🪪  argument.type                                                                                                   
  513    Parameter #1 $key of method Drupal\Core\Database\Connection::setKey() expects string, int|string given.             
         🪪  argument.type                                                                                                   
 ------ -------------------------------------------------------------------------------------------------------------------- 

I solved by explicity casting to string the values before passing them to Connection or Log methods.

Rebased and fixed ConnectionTest classes now that PHPStan checks strictly argument types

The bump commit is not showing up here, it does on GL though.

backport

Published CR.