Problem:
=======
Test "binlog.binlog_parallel_replication_marks_row" fails sporadically due to
result length mismatch.

Analysis:
=========
Test generates a binary log and it looks for certain words within the binary
log file and prints them. For example word like "GTID,BEGIN,COMMIT ...".
Binary log output contains base64 encoded characters. Occasionally the encoded
characters match with the above words and results in test failure.

+XwoFWxMBAAAALgAAAGEDAAAAAB8AAAAAAAEABHRlc3QAAnQxAAIDAwACFGTIDQ==
+AAAAAAAAAAAEEwQADQgICAoKCgGTIDw9

Fix:
===
Improve the regular expression to match exact words.

Let MTR check for error existence after running a test and return it back to user.

Error reporting itset might be much better, but first of all we need to see that
something went wrong.

wsrep_on parameter can be visible even when wsrep_on is set OFF
so we need to check variable_value from I_S also.

Set an explicit start and stop timeout of 900 seconds for the
MariaDB Server systemd service

Set an explicit start and stop timeout of 900 seconds for the
MariaDB Server systemd service

It is C++, not Java, the order of includes is often important.

It is C++, not Java, the order of includes is often important.

The lintian Debian tool is complaining about:
  'W: mariadb-test: manpage-has-errors-from-man
  usr/share/man/man1/mysql-test-run.pl.1.gz 246: warning [p 2, 6.0i, div
  '3tbd1,1', 0.3i]: can't break line'

See: https://salsa.debian.org/faust-guest/mariadb-10.3/-/jobs/431900

The following command permits to catch the problematic lines:
  $ groff -man -Tascii ./mysql-test-run.pl.1 | less

Closes #1419

$glob_mysql_test_dir was the wrong directory for strace output as
it was for in-tree builds only so failed for:
* out of tree builds
* --parallel; and
* --mem

strace output wasn't saved.

strace-option never replaced existing arguments (so ammended
documentation).

strace-client didn't accept an argument as described.

Replaced specification of client with this with 'stracer' to be
consistent with --debugger option.

For consistency with debugger options, --client-strace was added to
execute the strace on the mysqltest.

Example: Running one test

$ ./mtr --strace --client-strace funcs_1.is_table_constraints
Logging: ./mtr  --strace --client-strace funcs_1.is_table_constraints
vardir: /home/anel/mariadb/5.5/mysql-test/var
Checking leftover processes...
Removing old var directory...
 - WARNING: Using the 'mysql-test/var' symlink
Creating var directory '/home/anel/mariadb/5.5/mysql-test/var'...
Checking supported features...
MariaDB Version 5.5.67-MariaDB-debug
Installing system database...
 - SSL connections supported
 - binaries are debug compiled
Collecting tests...

==============================================================================

TEST                                      RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
funcs_1.is_table_constraints             [ pass ]   1270
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 1.270 of 3 seconds executing testcases

Completed: All 1 tests were successful

$ find -L . -name \*strace -ls
      653     56 -rw-r--r--   1 anel     anel        57147 Nov 29 15:08 ./var/log/mysqltest.strace
      646   1768 -rw-r--r--   1 anel     anel      1809855 Nov 29 15:08 ./var/log/mysqld.1.strace

Example: Running test in parallel

$ mysql-test/mtr --strace --client-strace  --mem --parallel=3  main.select
Logging: /home/dan/software_projects/mariadb-server/mysql-test/mysql-test-run.pl  --strace --client-strace --mem --parallel=3 main.select
vardir: /home/dan/software_projects/build-mariadb-10.3/mysql-test/var
Checking leftover processes...
Removing old var directory...
Creating var directory '/home/dan/software_projects/build-mariadb-10.3/mysql-test/var'...
 - symlinking 'var' to '/dev/shm/var_auto_0v2E'
Checking supported features...
MariaDB Version 5.5.67-MariaDB
 - SSL connections supported
Collecting tests...
Installing system database...

==============================================================================

TEST                                  WORKER RESULT   TIME (ms) or COMMENT
--------------------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
worker[3]  - 'localhost:16040' was not free
worker[2] Using MTR_BUILD_THREAD 301, with reserved ports 16020..16039
worker[3] Using MTR_BUILD_THREAD 303, with reserved ports 16060..16079
main.select                              w1 [ pass ]   7310
--------------------------------------------------------------------------
The servers were restarted 0 times
Spent 7.310 of 11 seconds executing testcases

Completed: All 1 tests were successful.

$ find mysql-test/var/ -name \*strace -ls
  5213766   1212 -rw-r--r--   1  dan      dan       1237817 May 20 16:47 mysql-test/var/1/log/mysqltest.strace
  5214733  13016 -rw-r--r--   1  dan      dan      13328335 May 20 16:47 mysql-test/var/1/log/mysqld.1.strace

$ mysql-test/mtr --strace --client-strace --strace-option='-e' --strace-option='trace=openat'  --mem --parallel=3  main.select
...
$ find mysql-test/var/ -name \*strace -ls
  5220790      8 -rw-r--r--   1  dan      dan          6291 May 20 17:02 mysql-test/var/3/log/mysqltest.strace
  5224140    308 -rw-r--r--   1  dan      dan        314356 May 20 17:02 mysql-test/var/3/log/mysqld.1.strace
$ more mysql-test/var/3/mysqltest.strace
1692  openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) =
-1 ENOENT (No such file or directory)
1692  openat(AT_FDCWD, "/home/dan/software_projects/mariadb-server/libmysql/.libs/tls/x86_64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOE
NT (No such file or directory)

Closes #600

init_settings.keywords and it's pointee are shared data. Protect them
with mutex too.

The required dependencies should be added through the autobake script,
to also cover distributions that do not support libcrack2.

The problem happens when MariaDB master replicates writes for only non InnoDB
tables (e.g. writes to MyISAM table(s)). Async slave node, in Galera cluster,
can apply these writes successfully, but it will, in the end, write gtid position in
mysql.gtid_slave_pos table. mysql.gtid_slave_pos table is InnoDB engine, and
this write makes innodb handlerton part of the replicated "transaction".
Note that wsrep patch identifies that write to gtid_slave_pos should not be replicated
and skips appending wsrep keys for these writes. However, as InnoDB was present
in the transaction, and there are replication events (for MyISAM table) in transaction
cache, but there are no appended keys, wsrep raises an error, and this makes the söave
thread to stop.

The fix is simply to not treat it as an error if async slave tries to replicate a write
set with binlog events, but no keys. We just skip wsrep replication and return successfully.

This commit contains also a mtr test which forces mysql.gtid_slave_pos table isto be
of InnoDB engine, and executes MyISAM only write through asyn replication.

There is additional fix for declaring IO and background slave threads as non wsrep.
These threads should not write anything for wsrep replication, and this is just a safeguard
to make sure nothing leaks into cluster from these slave threads.

Closes #1403

DbugParse(): removed mutex lock/unlock which should protect file writes only.
And no file writes happen in this function.

DbugFlush(): move mutex_unlock out of this method because fflush() doesn't
need any locking.

Slow stuff like mutex lock/unlock and accessing errno (TLS)
is moved to a more narrow scope.

This PR contains a mtr test for reproducing a failure with replicating create table as select statement (CTAS) through asynchronous mariadb replication to mariadb galera cluster.
The problem happens when CTAS replication contains both create table statement followed by row events for populating the table. In such situation, the galera node operating as mariadb replication slave, will first replicate only the create table part into the cluster, and then perform another replication containing both the create table and row events. This will lead all other nodes to fail for duplicate table create attempt, and crash due to this failure.

PR contains also a fix, which identifies the situation when CTAS has been replicated, and makes further scan in async replication stream to see if there are following row events. The slave node will replicate either single TOI in case the CTAS table is empty, or if CTAS table contains rows, then single bundled write set with create table and row events is replicated to galera cluster.

This fix should keep master server's GTID's for CTAS replication in sync with GTID's in galera cluster.

Make sure that the sort buffers can store atleast one sort key.
This is needed to make sure that all merge buffers are read else
with no sort keys some merge buffers are skipped because the code
makes a conclusion there is no data to be read.

Closes #1106

Problem:
========
CURRENT_TEST: binlog_encryption.rpl_corruption

mysqltest: In included file "./include/wait_for_slave_io_error.inc":
...
At line 72: Slave stopped with wrong error code
**** Slave stopped with wrong error code: 1743 (expected 1595,1913) ****

Analysis:
========
The test emulates the corruption at the various stages of replication for
example in binlog file, in network and in relay log etc. It verifies that all
corruption cases are handled through appropriate error messages.

The test cases which emulate network failure expect following errors.
--ER_SLAVE_RELAY_LOG_WRITE_FAILURE (1595)
--ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE (1743)

Ideally test should expect error codes as 1595 and 1743.
But the test actually waits on incorrect error code 1595,1913

Fix:
===
Added appropriate error code for 'ER_NETWORK_READ_EVENT_CHECKSUM_FAILURE'.
Replaced 1913 with 1743.

MDEV-19376 Repl_semi_sync_master::commit_trx assertion failure: ... || !m_active_tranxs->is_tranx_end_pos(trx_wait_binlog_name, trx_wait_binlog_pos)

The assert indicates that the current transaction got caught uncleaned from
the semisync master's cache when it is signaled to proceed upon its
ack receive.

The reason of missed cleanup turns out to be a flaw in the gtid
connect mode.
A submitted by connecting slave value of its last received event's
binlog file *name* was adopted into
{{Repl_semi_sync_master::m_reply_file_name}} as a part of semisync
initialization.

Notice that the initialization still refines the position part of the
submitted last received event's binlog coordinates.
The master side binlog filename:pos refinement is
specific to the gtid connect mode for purpose of computing the latest
binlog file to resume slave feeding from.
Effectively in the gtid connect mode the computed resumption filename:pos
may appear smaller in which case a new post-connect time committing
transaction may be logged with its filename:pos also less than the
submitted coordinates and that triggers the assert.

Fixed with making the semisync initialization to use the refined filename:pos.
It is guaranteed to be less than any new generated transaction's binlog:pos.

Make sure failure to find mariabackup binary does not terminate
the script silently, terminate with a clear error message instead

The issue here is the wrong estimate of the cardinality of a partial join,
the cardinality is too high because the function table_cond_selectivity()
returns an absurd number 100 while selectivity cannot be greater than 1.

When accessing table t by outer reference t1.a via index we do not perform any
range analysis for t. Yet we see TABLE::quick_key_parts[key] and
TABLE->quick_rows[key] contain a non-zero value though these should have been
remained untouched and equal to 0.

Thus real cause of the problem is that TABLE::init does not clean the arrays
TABLE::quick_key_parts[] and TABLE::>quick_rows[].
It should have done it because the TABLE structure created for any
instance of a table can be reused for many queries.

InnoDB: Assertion failure in file .../dict/dict0dict.cc line ...
InnoDB: Failing assertion: table->can_be_evicted

This fixes a regression that was caused by the fix of MDEV-20621
(commit a41d4297).
MySQL 5.6 (and MariaDB 10.0) introduced eviction of tables from
the InnoDB data dictionary cache. Tables that are connected to
FOREIGN KEY constraints or FULLTEXT INDEX are exempt of the eviction.
With the problematic change, a table that would already be exempt
from eviction due to FOREIGN KEY would cause the problem if there
also was a FULLTEXT INDEX defined on it.

dict_load_table(): Only prevent eviction if table->can_be_evicted holds.