When converting table identifiers to a new format,
some tables can be renamed twice, which subsequently
leads to the appearance of "false" auxiliary tables
belonging to another main (parent) table (which does
not actually have auxiliary tables).

This is because the table number is repeatedly added
to the aux_tables_to_rename vector inside the function
fts_check_and_drop_orphaned_tables.

To correct this error, we must add a check for the
occurrence of the table number in the aux_tables_to_rename
vector before adding a new element.

https://jira.mariadb.org/browse/MDEV-16656

Test changes only.

Failure is due missing .rdiff files for debug build as tests have
@have_debug combination.

MDEV-13879: galera.galera_wan fails in buildbot with Stray state UUID msg or with "Transport endpoint is not connected" or with a failure to start a node

Add correct suppressions and wait conditions for expected database
contents.

MDEV-14143: galera.galera_kill_smallchanges, galera.galera_kill_ddl fail in buildbot with "Last Applied Action message in non-primary configuration from member 0"

Add supression.

and debug builds. Modified version for 10.1 from following commit:

commit 8e688764
Author: Oleksandr Byelkin <sanja@mariadb.com>
Date:   Thu Sep 13 15:06:44 2018 +0200

    Fix of the test which has debug version

Move MW-328[A,B,C] to big tests as there seem to be big variation
on their execution times and sometimes that could lead timeout.

The problem occurs in 10.2 and earlier releases of MariaDB Server because the
Partition Engine was not pushing the engine conditions to the underlying
storage engine of each partition.  This caused Spider to return the first 5
rows in the table with the data provided by the customer.  2 of the 5 rows
did not qualify the WHERE clause, so they were removed from the result set by
the server.

To fix the problem, I have back-ported support for engine condition pushdown
in the Partition Engine from MariaDB Server 10.3.

Author:
  Jacob Mathew.

Reviewer:
  Kentoku Shiba.

Cherry-Picked:
  Commit eb2ca3d4 on branch bb-10.2-MDEV-16912

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