ib_counter_t: make all reads/writes to m_counter relaxed atomical

Reset query cache after every test case and add wait after
load infile.

to guarantee that it's destroyed when plugin deinit is called, not after

Unary minus operation for the smallest possible signed long long value
(LONLONG_MIN) is undefined in C++. Because of this, func_time.test
failed on ppc64 buildbot machines.

Fixing the code to avod using undefined operations.

This is fix is similar to "MDEV-7973 bigint fail with gcc 5.0"

alloc_root(): unpoison only requested amount of bytes instead of a
possible bigger aligned-sized buffer.

For the original test in 10.0 it was not really important if
find_user_wild() or find_user_exact() is used in sp_grant_privileges().
sp-security.test passed with either of them.

Fixing the test so it reliably fails with find_user_wild()
and pass with find_user_exact().

Add wsrep_sync_wait as we want INSERT to fail.

Wait in second node until tables with databases are created.

Test changes only.

             table->pos_in_locked_tables->table == table'
             failed in mark_used_tables_as_free_for_reuse

Assertion failure can be triggered by some DDL executed under LOCK TABLES
that holds lock for DDL target table multiple times (either explicitly or
implcitly).

When closing all table instances for given table (e.g. when preparing for
table removal during CREATE OR REPLACE), only one instance was removed
from m_locked_tables list.

Later we attempt to re-insert one of the instances in mysql_create_table()/
add_back_last_deleted_lock(), which wasn't actually removed. This leads
to m_locks_tables corruption, specifically loss of all following elements.

Then UNLOCK TABLE won't reset some table instances properly (specifically
pos_in_locked_tables), since they're not present in m_locked_tables.

Eventually such table instance gets released to table cache and then
re-used by subsequent statement, which triggers this assertion failure.

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.