MDEV-17173: correct parsing of 12.13.14.15:4444/xtrabackup_sst leavin…

Correcting commit e78e308e
$ . scripts/wsrep_sst_common.sh --address 12.13.14.15:4444/xtrabackup_sst ; set | grep WSREP_SST
WSREP_SST_OPT_ADDR=12.13.14.15:4444/xtrabackup_sst
WSREP_SST_OPT_ADDR_PORT=4444
WSREP_SST_OPT_AUTH=
WSREP_SST_OPT_BINLOG=
WSREP_SST_OPT_BINLOG_INDEX=
WSREP_SST_OPT_BYPASS=0
WSREP_SST_OPT_CONF='  '
WSREP_SST_OPT_DATA=
WSREP_SST_OPT_DEFAULT=
WSREP_SST_OPT_EXTRA_DEFAULT=
WSREP_SST_OPT_HOST=12.13.14.15
WSREP_SST_OPT_HOST_UNESCAPED=12.13.14.15
WSREP_SST_OPT_LSN=
WSREP_SST_OPT_MODULE=xtrabackup_sst
WSREP_SST_OPT_PATH=xtrabackup_sst
WSREP_SST_OPT_PORT=4444
WSREP_SST_OPT_PSWD=
WSREP_SST_OPT_SST_VER=
WSREP_SST_OPT_SUFFIX_DEFAULT=
WSREP_SST_OPT_SUFFIX_VALUE=
WSREP_SST_OPT_USER=

. scripts/wsrep_sst_common.sh --address 12.13.14.15:4444/xtrabackup_sst/1234/5676 ; set | grep WSREP_SST
WSREP_SST_OPT_ADDR=12.13.14.15:4444/xtrabackup_sst/1234/5676
WSREP_SST_OPT_ADDR_PORT=4444
WSREP_SST_OPT_AUTH=
WSREP_SST_OPT_BINLOG=
WSREP_SST_OPT_BINLOG_INDEX=
WSREP_SST_OPT_BYPASS=0
WSREP_SST_OPT_CONF='  '
WSREP_SST_OPT_DATA=
WSREP_SST_OPT_DEFAULT=
WSREP_SST_OPT_EXTRA_DEFAULT=
WSREP_SST_OPT_HOST=12.13.14.15
WSREP_SST_OPT_HOST_UNESCAPED=12.13.14.15
WSREP_SST_OPT_LSN=1234
WSREP_SST_OPT_MODULE=xtrabackup_sst
WSREP_SST_OPT_PATH=xtrabackup_sst/1234/5676
WSREP_SST_OPT_PORT=4444
WSREP_SST_OPT_PSWD=
WSREP_SST_OPT_SST_VER=5676
WSREP_SST_OPT_SUFFIX_DEFAULT=
WSREP_SST_OPT_SUFFIX_VALUE=
WSREP_SST_OPT_USER=

Test requires galera library version 25.3.24.

The bug was this scenario:
1. Join optimizer picks a range plan on index IDX1
   (This index doesn't match the ORDER BY clause, so sorting will be needed)
2. Index Condition Pushdown pushes a part of WHERE down. The pushed
   condition is removed from SQL_SELECT::cond
3. test_if_skip_sort_order() figures that it's better to use IDX2
   (as it will match ORDER BY ... LIMIT and so will execute faster)

3.1 It sees that there was a possible range access on IDX2. It tries to
   construct it by calling SQL_SELECT::test_quick_select(), but alas,
   SQL_SELECT::cond doesn't have all parts of WHERE anymore.
   So it uses full index scan which is slow.

(The execution works fine because there's code further in test_if_skip_sort_order()
which "Unpushes" the index condition and restores the original WHERE clause.
It was just the test_quick_select call that suffered).

Add suppression.

MDEV-13743: galera_toi_truncate may fail with: query 'reap' succeeded - should have failed with errno 1213

Replace sleep with debug sync point before insert commit to
make sure insert is not executed before truncate has started.

While executing CTAS galera applier thread can cause CTAS to abort and rollback. Rollback can take time causing applier thread to shutdown node after serial unsuccessful retries to apply transaction. Don't set lock_wait_timeout to zero to wait for lock.

On Unix, it is compiled-in datadir value.
On Windows, the directory is ..\data, relative to directory
mariabackup.exe

server uses the same logic to determine datadir.

Add missing test case with proper wait conditions for expected
node contents.

Add wait_conditions to wait expected node contents.

Start general log OFF and then truncate mysql.general_log and
use proper wait timeouts to make sure it is really empty.

Test changes only.

galera library used.

don't create static objects that destroy mutexes from destructors,
and don't destroy mutexes from .so destructor (on-unload) function.

if it happens after exit(), P_S will be long gone by that time

this fixes tokudb tests crashing on quantal-amd64

MDEV-17058: Test failure on wsrep.variables
MDEV-17060: Test failure on galera.galera_var_slave_threads

Fix incorrect calculation of increased applier (slave) threads.
Note that increase change takes effect "immediately" but we should
use proper wait condition to wait it. Reducing the number of
slave threads is not immediate as thread will only exit after a
replication event.

MDEV-10756: wsrep_sst_xtrabackup-v2 does not support innodb_data_home_dir

MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys

lowercase db and table names before prelocking.

Post-fix for 9180e866

This fixes failures on main.lowercase_table4 on Windows

           for blob column

Moved delete_stat_values_for_table_share() call to proper place.

Problem was that in SST log_bin_index name and directory was not
handled and passed to rsync SST script.

wsrep_sst_common.sh
	Read binlog index dirname and filename if --binlog-index
	parameter is provided. Read binlog filenames from that file
	from donor and write transfered binlog filenames to that
	file in joiner.

mysqld.cc, mysqld.h
	Moved opt_binlog_index_name from static to global and added
	it to extern.

wsrep_sst.cc

generate_binlog_index_opt_val
	New function to generate binlog index name if opt_binlog_index_name is
	given on configuration.

sst_prepare_other
	Add binlog index configuration to SST command.

wsrep_sst.h
	Add new SST parameter --binlog-index

Add test case.

The regression that was introduced in
commit 723f87e9
was fixed as part of MDEV-13333
(commit 3b37edee)
without a test case, because the MDEV-13333 test case
is even less deterministic than these ones.

MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys

Disable "Invalid (old?) table or database name" warning when
converting table names in InnoDB's get_foreign_key_info().

Because a name can be a temporary table name during the ALTER TABLE,
and some other thread can do SHOW CREATE TABLE for the other table
in the FK relationships _anytime_.

MDEV-16465 Invalid (old?) table or database name or hang in ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys

ALTER TABLE locks the table with TL_READ_NO_INSERT, to prevent the
source table modifications while it's being copied. But there's an
indirect way of modifying a table, via cascade FK actions.

After previous commits, an attempt to modify an FK parent table
will cause FK children to be prelocked, so the table-being-altered
cannot be modified by a cascade FK action, because ALTER holds a
lock and prelocking will wait.

But if a new FK is being added by this very ALTER, then the target
table is not locked yet (it's a temporary table). So, we have to
lock FK parents explicitly.

Backport of 794f71cb

table_already_fk_prelocked() was looking for a table in the wrong
list (not the complete list of prelocked tables, but only in its tail,
starting from the current table - which is always empty for the last
added table), so for circular FKs it kept adding same tables to the list
indefinitely.

Backport of d6d7e169