It is better to stay aligned with upstream in these names so we don't
divert in downstream Debian. Checking for external dependencies there
does not seem to be anything that is fixed on this name, and we can
simply proceed with the rename now.

For example https://codesearch.debian.net/search?q=mariadbcheck does not
show any external use of the name 'mariadbcheck' (yet!).

Fixup RocksDB test on s390x, not available there

See merge request mariadb-team/mariadb-10.3!17

Enable LZ4&Snappy for InnoDB and LZ4&Snappy&ZSTD for RocksDB

See merge request mariadb-team/mariadb-10.3!16

By default, MariaDB/RocksDB uses Snappy if available.

Update to upstream version '10.3.15'
with Debian dir fb5bc2ce7b08eab19de05159da22984d4979e885

This is needed for backwards compatibility with legacy mysql_config.

Don't run any excess mysqld processes in bootstrap mode, but let mysql_upgrade
take care of all database conversions and upgrade tricks. We can never have
all of mysql_upgrade contents as part of the mariadb-server postinstall script,
so don't even attempt it. A better approach is to patch mysql_upgrade is something
extra is needed.

Merge suitable parts of upstream commit
https://github.com/MariaDB/server/commit/7f6d88944c8afdcba12677840db8bc4e81cbe0db

Also drop legacy user table Password column fix dropped in upstream commit
https://github.com/MariaDB/server/commit/60ad33984090af2262d17232ceab1c1c9231fd24

Re-implement plugin rename similar to as done in upstream commit
https://github.com/mariadb/server/commit/fdfdea40f1b9d029de59131f54096c1b044ffdfa

By default the policy-rc.d exits with code 101 and prevents from services
inside Docker to start with the rationale that it is not needed as the
services will not run by default when a Docker container is started
anyway, but we want the mysql/mariadb service to run so that we can
simulate real install/upgrade scenarios.

TLS certs have been updated upstream so patch can be removed completely.

Update to upstream version '10.3.14'
with Debian dir 94eb82c93507b6179eda4eb1b5840ca0775c8fb6

Attempting to install libmariadb* in Debian Sid at the moment fails with:
  The following packages have unmet dependencies:
   libmariadb3 : Breaks: libmariadbclient18 but 1:10.3.13-1 is to be installed
   libmariadbclient18 : Depends: libmariadb3 (= 1:10.3.13-1) but 1:10.3.13-2 is to be installed
  E: Unable to correct problems, you have held broken packages.

This is because since 1:10.3.13-2 the package libmariadbclient18 is not
longer provided yet the orphan binary packages has not yet been cleaned
up from the Debian Sid repositories, so it creates a conflict by trying
to depend on a libmariadb3 revision no longer in Debian Sid repos.

Branches can have forward slashes (e.g. bugfix/123456) and thus the
artifact zip name should use slug instead of name. See note at
https://docs.gitlab.com/ee/ci/yaml/#artifactsname

Note that removing 'breaks-testbed' can cause regressions. See
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

Most of these SQL files are used to mysql_install_db to initiate a new
database, so therefore they belong to the -core package.

Turns out recent versions of MariaDB need resolveip to bootstrap the
database. Therefore this binary must be shipped as part of the -core
package.

Example of command that fails without resolveip:
  /usr/bin/mysql_install_db --defaults-file= --force \
  --basedir=/usr --datadir=db_data/