Introduce a major upgrade logic into CentralDB init-db script. The
implementation is based on the pg_upgrade [1] and postgresql-container [2]. We
can't use the latter upgrade scripts directly, because they require to use
provided entrypoints, which will need some more work from our side. We also
couldn't use `postgresql-upgrade` script directly, because it turns out it
doesn't allow to keep logs after upgrade if something went wrong.

The upgrade scenario looks like this:

* Check if the binaries version is newer than the data version and the upgrade
  is needed.

* Make sure the cluster was shutdown properly.

* Figure out if there is enough disk space available for the upgrade. The disk
  space needs to accomodate one mandatory backup and one temporary restored
  database to verify the backup. Hence the available size must be more than two
  times existing database size.

* Take a physical backup, and verify it via restoring a temporary copy of the
  database.

* Spin up a new PG15 database.

* Do the upgrade check first.

* If successfull, do the full upgrade, then swap old and new databases.

The script knows about a backup volume, and tries to use it for making a
backup. If it's not present, the main data volume will be used. The script is
not idempotent:

* If a backup was already taken, it will not be recreated.

* If a new PG15 database already exists, the upgrade will be aborted.

* If there is not enough disk space available, the upgrade will be aborted.

[1]: https://www.postgresql.org/docs/current/pgupgrade.html
[2]: https://github.com/sclorg/postgresql-container/

Use PostgreSQL 15 for central-db. Benefit from #14447 to handle upgrade scenarios.

Use PostgreSQL 15 for central-db. Benefit from #14447 to handle upgrade scenarios.