- if wsrep_on==OFF, unlock tables would resume provider even though it was not passed
  in FTWRL processing. This is fixed in this patch.

- reverted from tracking donor servicing thread. With xtrabackup SST,
  xtrabackup thread will call FTWRL and node is desynced upfront
- Skipping desync in FTWRL if node is operating as donor

- Calling FTWRL two times in a row caused desync error, this is fixed
  by making sub-sequent FTWRL calls bail out before wsrep operations

- enveloped FTWRL processing with wsrep desync/resync calls. This way FTWRL processing node
  will not cause flow control to kick in
- donor servicing thread is unfortunate exception, we must let him to pause provider as part
  of FTWRL phase, but not desync/resync as this is done as part of donor control on higher
  level

- some more code cleanup

- removed the off topic mtr test

- fixed the test case and extended with autoinc modification is master side

- test cases from PXC for reproducing the issue
- initial fix

Synced xtrabackup SST scripts from PXC source tree as of PXC 5.6.27-25.13
- PXC#480: xtrabackup-v2 SST fails with multiple log_bin directives in my.cn
- PXC#460: wsrep_sst_auth don't work in Percona-XtraDB-Cluster-56-5.6.25-25.
- PXC-416: Fix SST related issues.
- PXC-389: Merge remote-tracking branch 'wsrep/5.6' into 5.6-wsrep-pxc389
- Bug #1431101: SST does not clobber backup-my.cnf

Fixed threadpool_add_connection to use thd_prepare_connection()
to match thread-per-conection flow.

Transaction replay causes the THD to re-apply the replication
events from execution, using the same path appliers do. While
applying the log events, the THD's timestamp is set to the
timestamp of the event.
Setting the timestamp explicitly causes function NOW() to
always the timestamp that was set. To avoid this behavior we
reset the timestamp after replaying is done.

Update test results.

This changes variable wsrep_max_ws_size so that its value
is linked to the value of provider option repl.max_ws_size.
That is, changing the value of variable wsrep_max_ws_size
will change the value of provider option repl.max_ws_size,
and viceversa.
The writeset size limit is always enforced in the provider,
regardless of which option is used.

This patch includes two fixes:

1) Rollback when wsrep_max_ws_rows is exceeded would not switch
back to previous autocommit mode; and 2) Internal rows counter
would not be reset on implicit commits.

Update test results.

Variable wsrep_max_ws_rows limits the number of rows that a transaction
can insert/update/delete.

Disable output of MDL lock duration since there is no facility to retreive
it properly.

Reverted APC based fix. APC subsystem is not ready to serve metadata_lock_info
needs.

commit ef92aaf9
Author: Jan Lindström <jan.lindstrom@mariadb.com>
Date:   Wed Jun 22 22:37:28 2016 +0300

    MDEV-10083: Orphan ibd file when playing with foreign keys

    Analysis: row_drop_table_for_mysql did not allow dropping
    referenced table even in case when actual creating of the
    referenced table was not successfull if foreign_key_checks=1.

    Fix: Allow dropping referenced table even if foreign_key_checks=1
    if actual table create returned error.

windows: use GetProcAddress() to access internal server data structures
rhel5: CONNECT-JDBC requires at least Java 1.6

This used to be a compile failure. The defined structure isn't required
in the later versions of boost.
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>

Fix the replication failure caused by incorect initialization of
THD::invoker_host && THD::invoker_user.

Breakdown of the failure is this:
Query_log_event::host and Query_log_event::user can have their
LEX_STRING's set to length 0, but the actual str member points to
garbage. Code afterwards copies Query_log_event::host and user to
THD::invoker_host and THD::invoker_user.

Calling code for these members expects both members to be initialized.
Eg. the str member be a NULL terminated string and length have
appropriate size.

The bug is apparent when the username is longer than the rolename.
It is caused by a simple typo that caused a memcmp call to compare a
different number of bytes than necessary.

The fix was proposed by Igor Pashev. I have reviewed it and it is the
correct approach. Test case introduced by me, using the details provided
in the MDEV.
Signed-off-by: Vicențiu Ciorbaru <vicentiu@mariadb.org>

disable unstable tokudb tests,
(old change that was lost in a merge)

1. remove unnecessary rpl-tokudb combination file.
2. fix rpl_ignore_table to cleanup properly (not leave test
   grants in memory)
3. check_temp_dir() is supposed to set the error in stmt_da - do
   it even when called multiple times, this fixes a crash when
   rpl.rpl_slave_load_tmpdir_not_exist is run twice.

fix constants to stay 64-bit instead of being truncated by VS.
this fixes a hang on startup.

in particular, revert changes to the spider (avoid diverging from
  the upstream if possible)