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 methods has more limitations and caveats than provides real use:

1. It fetches all data in memory which is often inefficient (see #2718).
2. It fetches rows in memory one by one instead of using `fetchAll()`.
4. It doesn't allow to specify the statement fetch mode since it's instantiated internally.
5. It can be easily replaced with:
   ```php
   foreach ($conn->executeQuery($query, $params, $types) as $value) {
      yield $function($value);
   }
   ```

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`.

When the connection is lost or is closed, subsequent transaction will no longer be nested because they started in a brand new session. Our internal representation of the nesting shold take this into account

using params in query cache key generation.

Expressed PARAM_*_ARRAY through other constants to eliminate the dependency on the actual constant values