Fixes a deadlock between applier and its victim transaction.
The deadlock would manifest when a BF victim was waiting for some lock
and was signaled to rollback, and the same time its wait
timeout expired. In such cases the victim would return from
lock_wait_suspend_thread() with error DB_LOCK_WAIT_TIMEOUT, as opposed to
DB_DEADLOCK. As a result only the last statement of the victim would rollback,
and eventually it would deadlock with the applier.

- Erronously removed call to wsrep_xid_init() in previous commit.

- Removes useless call to wsrep_xid_init() in wsrep_apply_events().
  Transaction's xid is already initialized at that point.
- Adds call to wsrep_set_SE_checkpoint() for committing TOI events
  in the applier side.
- Includes test case that reproduced the issue.

- Moves call wsrep_free_status() to THD::cleanup_after_query().
  Wsrep status variables were previously freed only on SHOW STATUS.
- Removes valgrind suppression from mysql-test/valgrind.

Added schema info to wsrep messages above debug level.

Conflicts:
	mysql-test/include/mtr_check.sql
	mysql-test/suite/galera/r/galera_log_bin.result
	mysql-test/suite/galera/t/galera_log_bin.test

- created mtr test for testing explicit desyncing with RSU mode DDL

- skipping desync and resync before and after DDL execution in RSU mode, if wsrep_desync is set upfront

A deadlock can occur when the wsrep applier thread while
executing FLUSH TABLES waits for MDL lock owned by other
local transactions, which in turn are waiting for commit
order if their seqno comes after one assigned to FLUSH
TABLES.
Fixed by making sure that the wsrep applier thread while
executing FLUSH TABLES does not wait for table share(s)
to be removed from table definition cache.

Addendum: Save thd's server_status & option_bits before
setting the thread specific pointer.

In wsrep BF we have already took lock_sys and trx
mutex either on wsrep_abort_transaction() or
before wsrep_kill_victim(). In replication we
could own lock_sys mutex taken in
lock_deadlock_check_and_resolve().

As a fix for MDEV-8208, for initial wsrep threads, the
invocation of init_for_queries() was moved after plugins
were initialized. Due to which, OPTION_BEGIN bit of wsrep
applier THD (originally set in wsrep_replication_process)
got reset due to implicit commit within init_for_queries().
As a result, events from a multi-statement transaction from
another node were committed separately by the applier thread,
which leads to an assertion as they all carry same seqno.

Fixed by making sure that variable.option_bits are restored
post init_for_queries(). Also restored server_status.
Added a test case.

            of the plugins

Removed exit() from daemon_example, pass error to caller instead.
Also removed unused my_abort_hook.

Check now allows zero length decimals too.

(backporting Adam Chainz patch to 10.0)

they used to be unstable, fixed in 7.1.8
and apparently broken again now

* mostly update result files
* also updating test/include files to match 5.6

* use --sort_result in test files as needed
* remove old and wrong mariadb-5.3 related partitioning hack
   from ha_tokudb.cc

Fixed moving charset from definition to the value.

Update modified-counter also if update effects non-indexed columns.

Backport pull request #125 from grooverdan/MDEV-8923_innodb_buffer_pool_dump_pct to 10.0

WL#6504 InnoDB buffer pool dump/load enchantments

This patch consists of two parts:

    1. Dump only the hottest N% of the buffer pool(s)
    2. Prevent hogging the server duing BP load

From MySQL - commit b409342c43ce2edb68807100a77001367c7e6b8e

Add testcases for innodb_buffer_pool_dump_pct_basic.

Part of the code authored by Daniel Black

MDEV-9276: MySQL Bug #78754: FK definitions missing from SHOW CREATE TABLE in "innodb_read_only" mode

As galera node (slave) received query log events from an async
replication master, it partially wrote the updates made to replication
state table (mysql.gtid_slave_pos) to galera transaction writeset post
TOI. As a result, the transaction handle, thus created within galera,
was never freed/purged as the corresponding trx did not commit.
Thus, it kept piling up for every query log event and was only reclaimed
upon server shutdown when the transaction map object got destructed.
Fixed by making sure that updates in replication slave state table
are not written to galera transaction writeset and thus, not replicated
to other nodes.

Fix logic around retrying failed Windows async IO as synchronous IO . os_file_write/read macros were wrong (had wrong number of args), among other things

In wsrep brute force (BF) we have already took lock_sys and trx
mutex either on wsrep_abort_transaction() or
before wsrep_kill_victim().