Restore tests for FLUSH commands supported by MariaDB.

* Total order isolation was started twice for FLUSH TABLES, from
  reload_acl_and_cache() and from mysql_execute_command(). Removed
  the reload_acl_and_cache() part.
* Removed PXC specific stuff from MTR tests

- Eliminates code duplication in query cache patch
- Reduces the number of iterations in mysql-wsrep#201.test
  to shorten the execution time
- Adds a new test case that exercises more scenarios

- Restore FLUSH commands supported by MariaDB (removed in
the previous commit)
- Adjust test case

Added following:

        FLUSH CLIENT_STATISTICS
        FLUSH INDEX_STATISTICS
        FLUSH TABLE_STATISTICS
        FLUSH THREAD_STATISTICS
        FLUSH USER_STATISTICS

pertaining to USER STATISTICS
https://www.percona.com/doc/percona-server/5.6/diagnostics/user_stats.html

        FLUSH CHANGED_PAGE_BITMAPS

pertaining to changed page tracking.
https://www.percona.com/doc/percona-server/5.6/management/changed_page_tracking.html

Also, added tests for them.

(cherry picked from commit 7efe49010c7f217663f364657090812b4723f426)

Conflicts:
	mysql-test/suite/galera/r/galera_flush.result
	mysql-test/suite/galera/r/galera_flush_gtid.result
	mysql-test/suite/galera/t/galera_flush.test
	sql/sql_parse.cc

The admin commands in question are:
    > OPTIMIZE
    > REPAIR
    > ANALYZE

For LOCAL or NO_WRITE_TO_BINLOG invocations of these commands, ie

    OPTIMIZE LOCAL TABLE <t1>

they are not binlogged as expected.

Also, in addition, they are not executed under TOI.

Hence, they are not propagated to other nodes.

The effect is same as that of wsrep_on=0.

Also added tests for this.

A WSREP_DEBUG for wsrep_register_hton has also been added.

The galera_flush_local test has also been updated for verifying that effects
of  NO_WRITE_TO_BINLOG / LOCAL are equivalent to wsrep_on=0 from wsrep
perspective.

(cherry picked from commit 5065122f94a8002d4da231528a46f8d9ddbffdc2)

Conflicts:
	sql/sql_admin.cc
	sql/sql_reload.cc
	sql/wsrep_hton.cc

Galera MTR Tests: stability fix for galera_gcs_fragment.test (TCP port was output to the .result file)

- Fixes query cache so that it is aware of wsrep_sync_wait.
  Query cache would return (possibly stale) results to the
  client, regardless of the value of wsrep_sync_wait.
- Includes the test case that reproduced the issue.

Merge fix to XtraDB engine.

- Adds runtime check wsrep_on(), to not interfere with default
  innodb behavior.

- Avoid calling wsrep->stats_free() directly, instead, use wsrep_free_status().

- Moves cleanup of status vars to function export_wsrep_status_to_mysql().

Merge fix to XtraDB engine.

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.