do not fallback to malloc(), always return properly aligned buffer

One may not call memcpy(dst, src=NULL, size), even if size==0.

Remove Query_tables_list::lock_tables_state - it is not used and it causes
errors like this:

sql_lex.h:1675:7: runtime error: load of value 2779096485, which is not a
valid value for type 'enum_lock_tables_state'

Fix wrong typecast

crashes on Debian 10

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