Deprecate usage of Connection::getDriverClass for some classes, and use standard autoloading instead

A first patch. While overriding the Connection methods that call getDriverClass in the driver-specific classes with direct indication of the class to use is (relatively) straigthforward, the use of the method to replace query extenders with driver-specific classes is not. AFAICS this in more recent times was done with backend-overridable services; could that be applied here too?

I have opened #3217699: Convert select query extenders to backend-overrideable services for #3. There's a PoC there, comments appreciated.

#3217699: Convert select query extenders to backend-overrideable services would help here, so postponing on that for the moment.

Rebased to 9.4 and rerolled

On this

1) Drupal\FunctionalTests\Installer\InstallerNonDefaultDatabaseDriverTest::testInstalled
Exception: Error: Class "Drupal\mysql\Driver\Database\mysql\ExceptionHandler" not found
Drupal\mysql\Driver\Database\mysql\Connection->exceptionHandler()() (Line: 499)

I think we are hitting #3256642: Introduce database driver extensions and autoload database drivers' dependencies here, we are blocked on it

Agh no #3256642: Introduce database driver extensions and autoload database drivers' dependencies is D10 only, need to figure out 9.4

With #3256642: Introduce database driver extensions and autoload database drivers' dependencies the D10 patch will be much simpler and cleanup a lot, so I am still keen on holding this (both 9.4 and 10) on that. But the MR towards 9.4 should pass now.

Unfortunately, #3217699: Convert select query extenders to backend-overrideable services was reverted and reopened so now this is postponed on 2 issues.

Maybe we can still get on after #3256642: Introduce database driver extensions and autoload database drivers' dependencies commit leaving aside, alas, #3217699: Convert select query extenders to backend-overrideable services.

Let's make this issue a bit less boastful. The MR here helps a lot reducing boilerplate classes in database drivers extending from core ones.

It’s not the SAME code actually. Each method instantiates a class either in the same namespace of the Connection class, or in the core lib, depending in the use imports at the beginning of each driver’s Connection class. In D11 we might change the core abstract Connection methods to instantiate the classes on Database\Query, and use default inheritance in drivers’ extending Connection classes. We can’t do that now without breaking BC. In any case, most of the classes even in core drivers DO extend from the core classes, so the driver specific methods will stay.

@daffie IMHO we should avoid using properties to store the class whereabouts, that replace native autoloading with our magic. That's what protected $statementWrapperClass is doing, and I think we should also change that at some point.

I know this looks like adding boilerplate, but it's actually not. These are methods that are there just to create a proper instance of a class depending on the driver. In our current predicament, we can not leverage inheritance because of BC concerns. But once we can, there will be quite some cleanup possible - the same cleanup that it's possible with this MR in contrib drivers that extend from core ones and do not have to override a specific class (see the test drivers in the MR already).

Better than many words, I'll post here 'how' D11 could look like in this respect.

@daffie here's the idea per #28; Upsert and Schema are abstract classes in core, so every driver must implement its ones. But the rest of the classes we can inherit from the core Connection in D11, unless there are overrides.

EDIT - I shouldn't have removed MySql Insert class... but here is to illustrate, not to make it work.

Should we not deprecate getDriverClass() entirely here? Are there any other calls to it with other arguments?

Unfortunately not, #3217699: Convert select query extenders to backend-overrideable services blocks that deprecation since Query\Select::extend() uses it.

Also #28/#30 imply that we might not make all those @todo methods abstract?

Yes, NW to adjust the @todo(s) - so we need to make schema and upsert abstract since the classes are abstract, all others should be implementations instantiating the corresponding Query\* base class.

Rebased.

Here it comes, @longwave. Thanks

Thank you. Edited the CR to reflect the approach that was eventually committed.

Filed #3375919: Deprecate usage of Connection::getDriverClass for 'Install\Tasks' for follow up.