Testing the implementations of this method requires partial mocking of the implementing class which makes it impossible to make them `final` (#3590).

Additionally, this API breaks the encapsulation of the driver layer: instead of exposing the fact of whether the connection will perform a query to detect the server version, the driver should just instantiate a platform corresponding to a connection.

The rationale behind introducing this method (#487) is really questionable:

> This is also required for drivers that cannot return the database server version without an additional query (performance reasons).

1. There's no evidence that an underlying driver that exposes the server version via its API doesn't make a request of any kind to the server.
2. For an application that works with any realistic database, a query like `SELECT VERSION()` wouldn't be a performance bottleneck.
3. Even if it was, it's always possible to specify the platform version upfront. Otherwise, the current logic of falling back to a default platform may cause undefined behavior of the application (we don't test the compatibility of the lowest level of the DBAL platform with all supported server versions). Remember, “If it doesn’t work, it doesn’t matter how fast it doesn’t work.”

The method is not used for anything else than skipping tests for specific drivers. Cross-driver portability should be established by drivers, not outside of them based on their name.

1. `FetchMode::STANDARD_OBJECT` and `FetchMode::CUSTOM_OBJECT` are no longer supported.
2. `FetchMode::COLUMN` with a non-zero index is no longer supported.
3. Incompatible change in the `Connection::fetchColumn()` signature where the 3rd argument is now `$types`, not `$columnIndex`.