Fix test failure on galera_flush_local.

Fix test failure on galera_concurrent_ctas

    Fortify wsrep_hton so that wsrep calls are not done to NULL-pointers.

To disallow equality propagation for DATETIME with non-zero YYYYMMDD part we were setting null_value to true.
This caused issues when we were calculating selectivity for a condition as this returned IMPOSSIBLE WHERE.

The issue is resolved by not setting null_value to true for DATETIME with non-zero YYYYMMDD.

Eliminated last exit() call from libmysqld.

Unlike commit a54abf01 claimed,
the caller of THD::awake() may actually hold the InnoDB lock_sys->mutex.
That commit introduced a deadlock of threads in the replication slave
when running the test rpl.rpl_parallel_optimistic_nobinlog.

lock_trx_handle_wait(): Expect the callers to acquire and release
lock_sys->mutex and trx->mutex.

innobase_kill_query(): Restore the logic for conditionally acquiring
and releasing the mutexes. THD::awake() can be called from inside
InnoDB while holding one or both mutexes, via thd_report_wait_for() and
via wsrep_innobase_kill_one_trx().

ha_innobase::unlock_row(): Use a relaxed version of the
trx_state_eq() debug assertion, because rr_unlock_row()
may be invoked after an error has been already reported
and the transaction has been rolled back.

By definition, c_lock->trx->lock.wait_lock==c_lock cannot hold.
That is, the owner transaction of a lock cannot be waiting for that
particular lock. It must have been waiting for some other lock.
Remove the dead code related to that. Also, test c_lock for NULLness
only once.

The caller of THD::awake() should never hold any InnoDB mutexes,
so we can always acquire lock_sys->mutex and trx->mutex.

MDEV-13549 Fix and re-enable test galera.galera_var_slave_threads

Two changes were made to the test:

1) Suppress warning "Refusing exit for the last slave thread."
   This warning was already suppressed, but on the wrong node.

2) The test occasionally fails because it expects that the
   number of applier threads changes immediately after
   changing the value of ```variable wsrep_slave_threads```.
   Which is not true. This patch turns snippets like this:

   ```
   SET GLOBAL wsrep_slave_threads = x;
   SELECT COUNT(*) = x FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'system user';
   ```

   Into proper wait_conditions:

   ```
   SET GLOBAL wsrep_slave_threads = x;
   let $wait_condition = SELECT COUNT(*) = x FROM ...;
   --source include/wait_condition.inc
   ```

MDEV-14144 Fix for MTR tests complaining "Query didn't return a result set"

MDEV-13549 Fix for test galera.galera_var_max_ws_rows

MDEV-13549 Fix and re-enable MTR test galera.MW-366

MDEV-13549 Fix and re-enable test galera.galera_bf_abort_for_update

MDEV-13549 Fix and re-enable test galera.MW-286

These tests were also subject to error "Wrong usage of mutex
'LOCK_wsrep_thd' and 'LOCK_thd_kill'".

"mtr func_date_add" failed on 32-bit platforms. Removing a wrong case to "long".
Both values[] and log_10_int[] are arrays of "ulonglong", no cast is needed.

musl ships the header for other purposes, but makecontext is not
implemented. fix the check to detect if makecontext is implemented
before enabling code using it.

Test passes reliably after applying missing commit from upstream.

The test was not deterministic as it would not wait for the second
INSERT to be applied (and thus the victim transaction rolled back).

Test galera.MW-366 is not deterministic and depends on timing assumptions.
The test occasionally fails after checking the number of 'system user'
processes in processlist after changing the value of variable global
wsrep_slave_threads, like this:
```
SET GLOBAL wsrep_slave_threads = x;
--sleep 0.5
SELECT COUNT(*) = x FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'system user';
```

The problem is that the number of slave threads is internally adjusted
'asynchronously', and it may take some time to spawn/kill new threads,
especially in a heavily loaded system.

This patch removes the '--sleep 0.5' statements from the test and replaces
those with appropriate wait conditions, like this:
```
SET GLOBAL wsrep_slave_threads = x;
let $wait_condition = SLECT COUNT(*) = x FROM ...;
--source include/wait_condition.inc
```

This patch re-enables test galera.galera_var_max_ws_rows.
The test did not work because there were two distinct places where
the server was incrementing member THD::wsrep_affected_rows before
enforcing wsrep_max_ws_rows. Essentially, the test would fail because
every inserted row was counted twice.
The patch removes the extra code.

           replicate_events_marked_for_skip=FILTER_ON_MASTER

[Note this is a cherry-pick from 10.2 branch.]

When events of a big transaction are binlogged offsetting over 2GB from
the beginning of the log the semisync master's dump thread
lost such events.
The events were skipped by the Dump thread that found their skipping
status erroneously.

The current fixes make sure the skipping status is computed correctly.
The test verifies them simulating the 2GB offset.

Based on contribution by Daniel Black.

fts_sync(): If the dict_table_t::to_be_dropped flag is set,
do not "goto begin_sync".

Also, clean up the way how dict_index_t::index_fts_syncing
is cleared.

It looks like this regression was introduced by merging
Oracle Bug #24938374 MYSQL CRASHED AFTER LONG WAIT ON DICT OPERATION LOCK
WHILE SYNCING FTS INDEX
https://github.com/mysql/mysql-server/commit/068f8261d4c1e134965383ff974ddf30c0758f51
from MySQL 5.6.38 into MariaDB 10.0.33, 10.1.29, 10.2.10.
The same hang is present in MySQL 5.7.20.

Galera MTR Tests: Modify mysqltest so that if a --let = `SELECT ...` query is interrupted, the test does not fail but the error is communicated to caller

The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should
disable materialisation for such a case.

MDEV-14648 Restore fix for MySQL BUG#39053 - UNINSTALL PLUGIN does not allow the storage engine to cleanup open connections

ha_close_connection(): Do invoke the method also for plugins
for which UNINSTALL PLUGIN was deferred due to open connections.

Test MW-286 occasionally failed with error the following message:

```
safe_mutex: Found wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill'
Mutex currently locked (in reverse order):
LOCK_thd_kill                     mariadb-server/sql/sql_class.h  line 3535
LOCK_wsrep_thd                    mariadb-server/sql/wsrep_thd.cc  line 88
```

The fix consists in calling thd->reset_killed() in wsrep_mysql_parse() after
LOCK_wsrep_thd is unlocked. Which avoids the taking locks LOCK_wsrep_thd and
LOCK_thd_kill in reverse order.