Removal of unnecessary savepoints from PostgreSQL

Problem/Motivation

The database driver for PostgreSQL is now mimicking how the database driver
for MySQL/MariaDB does things. To make the database driver for PostgreSQL work
like the one for MySQL/MariaDB it adds a lot of savepoints in transactions.
Savepoints in transactions are not free. Starting and ending a savepoint are
both a round trip to the database. Every Insert, Update, Upsert and Select
query uses savepoints. Instead of a single round trip to the database, we
have 3 round trips to the database. There is some performance improvement
possible.

Why the savepoints are there

PostgreSQL: any error poisons the whole transaction. When a
statement fails inside a transaction — even an "expected" failure like a
duplicate-key violation or a query against a table that doesn't exist yet —
PostgreSQL marks the entire transaction as aborted. Every subsequent statement
is rejected with

ERROR: current transaction is aborted, commands ignored
until end of transaction block

until you ROLLBACK. You
can't just catch the exception in PHP and carry on; the transaction is dead.

The only way to recover part of a transaction is a savepoint:
SAVEPOINT s1 before the risky statement, then
ROLLBACK TO SAVEPOINT s1 if it fails (which restores the
transaction to a usable state) or RELEASE SAVEPOINT s1 if it
succeeds.

MySQL/InnoDB: only the statement fails. When a statement
errors, InnoDB rolls back just that statement (or in a few edge cases like
deadlock, the transaction — but it tells you). The transaction itself remains
open and usable, so a catch block in PHP can simply try something else and
continue. No savepoint needed.

Why this matters for Drupal specifically: Drupal core has
several patterns that deliberately race or probe:

• Merge / upsert-style logic: try an INSERT, catch the
  integrity-constraint violation, fall back to UPDATE.
• Cache, lock, flood, key-value, queue backends: write to a table, and if
  it fails with "table not found", lazily create the table and retry
  (ensureTableExists() pattern).
• ExceptionHandler for inserts catching duplicate-key
  exceptions.

On MySQL these catch-and-retry patterns just work, even when the caller has
an outer transaction open (e.g. during entity save). On PostgreSQL, without a
savepoint around the risky statement, the caller's transaction would be
aborted as collateral damage — an entity save would blow up because a
cache-set inside it hit a duplicate key. That's why the pgsql driver
historically wraps such statements in savepoints (addSavepoint()
/ releaseSavepoint() / rollbackSavepoint() on the
connection), and why this work moves those savepoints out of blanket driver
wrapping and into the specific consumers that actually do catch-and-continue —
the savepoint round-trips cost extra network chatter and each savepoint has
server-side overhead, so you only want them where a failure is genuinely
expected and recoverable.

Proposed resolution

1. All savepoints in the Insert, Select, Update, and Upsert queries are
   removed.
2. The backend database storage classes that use the trick with ensure
   table exists have been replaced with a verify that the table exists.

Performance testing

Base queries

Backend storage classes

I have tested the baseline to the PR and the overall difference is about 2x
to 2.5x. performance improvement.

Remaining tasks

To make that possible we need a fundamental change in how the database
driver for PostgreSQL works. Does the database driver keep mimicking the
database driver for MySQL/MariaDB or are we going to change it and optimize
the database driver for working with a PostgreSQL database? That decision is
for the Drupal Core backend framework managers and maybe even the release
managers.

For the committer

The changes to the .gitlab-ci.yml file need to be removed before merging!