If a conflict happens under wsrep_on, the THD's wsrep_conflict_state
is typically set to MUST_ABORT and cleared later, when transaction is
aborted. However, when wsrep_on is disabled, no check is performed to
see whether wsrep_conflict_state is set. So this potentially creates
spurious deadlock errors on the subsequent statement that runs with
wsrep_on enabled.
To avoid this problem wsrep_thd_set_conflict_state() sets the conflict
state only if wsrep_on is enabled.

Galera MTR Tests: Run galera_pc_weight on freshly started servers in order to prevent interaction with other tests

- At startup time global wsrep_on is set too late and some wsrep paths may be executed
  because of this. e.g. replication slave restart could happen before wsrep_on state is defined.
- This fix checks both global wsrep_on and wsrep_provider values to determine if wsrep
  processing should happen
- Fix affects all instances where WSREP_ON macro is used

Galera MTR Tests: force galera_3nodes.galera_pc_bootstrap.test to run on a fresh cluster in order to avoid interaction with galera_3nodes.galera_innobackupex_backup.test

Galera MTR Tests: Fortify galera_restart_nochanges.test against sporadic failures due to node not being ready immediately after restart

Galera MTR Tests: Add test for GAL-382, codership/galera#382 - InnoDB: Failing assertion: xid_seqno > trx_sys_cur_xid_seqno in trx0sys.cc line 356

MW-259 - moved wsrep desync/resync calls from wsrep_desync_update() to wsrep_desync_check() method which does not hold the lock and is arguably a more fitting place to change provider state - before changing the actual variable value.

MW-258 - RSU DDL should not rely on the global wsrep_desync variable value and should always try to desync on its own.

- popping PS reprepare observer before BF aborted PS replaying begins
  dangling observer will cause failure in open_table() ater on
- test case for this anomaly

- changed the condition when to do implicit desync as part of FTWRL to
  cover only case when node is PC and synced. Donor node has alreaydy desycned
  and other states mean that node is not in cluster, so desync is not even possible.

- 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.