MDEV-21953 deadlock between BACKUP STAGE BLOCK_COMMIT and parallel
replication

Fixed by partly reverting MDEV-21953 to put back MDL_BACKUP_COMMIT locking
before log_and_order.

The original problem for MDEV-21953 was that while a thread was waiting in
for another threads to commit in 'log_and_order', it had the
MDL_BACKUP_COMMIT lock. The backup thread was waiting to get the
MDL_BACKUP_WAIT_COMMIT lock, which blocks all new MDL_BACKUP_COMMIT locks.
This causes a deadlock as the waited-for thread can never get past the
MDL_BACKUP_COMMIT lock in ha_commit_trans.

The main part of the bug fix is to release the MDL_BACKUP_COMMIT lock while
a thread is waiting for other 'previous' threads to commit. This ensures
that no transactional thread keeps MDL_BACKUP_COMMIT while waiting, which
ensures that there are no deadlocks anymore.

This ensures that all tests can be run.
Before this patch some encryption test failed

This is to ensure code in 10.4 and 10.5 is logically identical for this
variable

When process is aborted WSREP deinitialization and memory cleanup is not properly handled.  Other reported leaks are in Galera library and should be fixed there.

Fixes (rare) case when mysql-test is included into "noinstall" ZIP.

Port some CMake tweaks of commit 4adc1269
from 10.5.

It turns out that we must check for DISCARD TABLESPACE both
when the table is being rebuilt and when the AUTO_INCREMENT
value of the table is being added.

This was caught by the test innodb.alter_missing_tablespace.
Somehow I failed to run all tests. Sorry!

The statement ALTER TABLE...DISCARD TABLESPACE is problematic,
because its designed purpose is to break the referential integrity
of the data dictionary and make a table point to nowhere.

ha_innobase::commit_inplace_alter_table(): Check whether the
table has been discarded. (This is a bit late to check it, right
before committing the change.) Previously, we performed this check
only in a specific branch of the function commit_set_autoinc().

Note: We intentionally allow non-rebuilding ALTER TABLE even if
the tablespace has been discarded, to remain compatible with MySQL.
(See the various tests with "wl5522" in the name, such as
innodb.innodb-wl5522.)

The test case would crash starting with 10.3 only, but it does not hurt
to minimize the code and test difference between 10.2 and 10.3.

dict_load_table_low(): Copy the 'discarded' flag to file_unreadable.
This allows to avoid a potentially harmful call to dict_stats_init()
in ha_innobase::open().

The test that was added in commit e05650e6
would break a subsequent run of a test encryption.innodb-bad-key-change
because some pages in the system tablespace would be encrypted with
a different key.

The failure was repeatable with the following invocation:

./mtr --no-reorder \
encryption.create_or_replace,cbc \
encryption.innodb-bad-key-change,cbc

Because the crash was unrelated to the code changes that we reverted
in commit eb38b1f7
we can safely re-apply those fixes.

Add error printout when mysql.wsrep_streaming_log lock
fails. However, tests are very undeterministic and not
suitable for mtr environment. Thus, they are removed.

After DISCARD TABLESPACE, the tablespace of a table will no longer
exist, and dict_get_and_save_data_dir_path() would invoke
dict_get_first_path() to read an entry from SYS_DATAFILES.
For some reason, DISCARD TABLESPACE would not to remove the entry
from there.

dict_get_and_save_data_dir_path(): If the tablespace has been
discarded, do not bother trying to read the name.

Side note: The tables SYS_TABLESPACES and SYS_DATAFILES are
redundant and subject to removal in MDEV-22343.

This reverts commit e33f7b6f.
The change seems to have introduced intermittent failures of the test
encryption.innodb-bad-key-change on many platforms.

The failure that we were trying to address was not reproduced on 10.2.
It could be related to commit a7dd7c89
(MDEV-23651) or de942c9f (MDEV-15983)
or other changes that reduced contention on fil_system.mutex in 10.3.

The fix that we are hereby reverting from 10.2 seems to work fine
on 10.3 and 10.4.

This is just to make sure no ExecStartPre/Post actions from the
multi-instance MariaDB service definition are executed
when a user attempts to start mariadb@bootstrap.

Fixes: 3723c70a

We omit commit a3bdce8f
and commit a0e2a293
because they would make the test galera_3nodes.galera_gtid_2_cluster
fail and disable it.

This was forgotten in commit a9d8f5c1.

Let us shrink the test encryption.create_or_replace so that it can
run on the CI system, also on the embedded server.

encryption.create_or_replace_big: Renamed from the original test,
with the subset of encryption.create_or_replace omitted.

The test encryption.create_or_replace would occasionally fail with
a warning message from fil_check_pending_ops().

fil_crypt_find_space_to_rotate(): While waiting for available
I/O capacity, check fil_space_t::is_stopping() and release a
handle if necessary.

fil_space_crypt_close_tablespace(): Wake up the waiters in
fil_crypt_find_space_to_rotate().

log_group_read_log_seg() returns error when:

1) Calculated log block number does not correspond to read log block
number. This can be caused by:
  a) Garbage or an incompletely written log block. We can exclude this
  case by checking log block checksum if it's enabled(see innodb-log-checksums,
  encrypted log block contains checksum always).
  b) The log block is overwritten. In this case checksum will be correct and
  read log block number will be greater then requested one.

2) When log block length is wrong. In this case recv_sys->found_corrupt_log
is set.

3) When redo log block checksum is wrong. In this case innodb code
writes messages to error log with the following prefix: "Invalid log
block checksum."

The fix processes all the cases above.

Fix assertion text it was too tight for some systems.

This is backport from 10.4 and for Galera 3.

Fix assertion text it was too tight for some systems.

The presumed reason for the error is that the file was opened
by 3rd party antivirus or backup program, causing ERROR_SHARING_VIOLATION
on rename.

The fix, actually a workaround, is to retry MoveFileEx couple of times
before finally giving up. We expect 3rd party programs not to hold file
for extended time.

MDEV-23574 : galera_3nodes.galera_ipv6_mariabackup_section MTR failed: Could not open '../galera/include/have_mariabackup.inc'

Test case and configuration cleanup.

Add wait_condition to wait correct cluster configuration.

MDEV-21655 : galera.galera_wan_restart_ist MTR fails sporadically: WSREP did not transition to state READY

Replace sleeps with proper wait_conditions to wait correct
cluster configuration.