- errno handling in wsp::env::append() method, where error could be returned by mistake
  - return code of sst_prepare_other() when pthread_create() fails - it was returning positive error code which by convention is treated as success.

Synced xtrabackup SST fixes from Percona tree (as of PXC 5.6.24-25.11 release). This fixes/adresses the following LP bugs:
  - LP1380697: wsrep_sst_xtrabackup-v2 doesn't stop when mysql is SIGKILLed. (full fix for this (as engineeered by Percona) requires Linux-specific patch that we don't carry, but keep xtrabackup scripts as close as possible)
  - LP1399134: Log the innobackupex/SST logs in SST to syslog if possible. (fixed)
  - LP1405668: Race condition between donor and joiner in PXB SST. (fixed)
  - LP1405985: Fail early if xtrabackup_checkkpoints is missing. (fixed)
  - LP1407599: wsrep_sst_xtrabackup-v2 script causes innobackupex to print a false positive stack trace into the log. (fixed)
  - LP1441762: IST Fails with SST script error. (fixed)
  - LP1451670: Fail when move-back fails in xtrabackup SST. (fixed)

  1. Passes wsrep_sst_auth_value to SST scripts via WSREP_SST_OPT_AUTH envronmental variable, so it never appears on the command line
  2. In mysqldump and xtrabackup* SST scripts which rely on MySQL authentication, instead of passing password on the command line, SST script sets MYSQL_PWD environment variable, so that password also never appears on the mysqldump/innobackupex command line.

Do not replicate commands from check-warnings.test to other
nodes in the cluster.

When wsrep is enabled, for any update on innodb tables, the
corresponding keys are appended to galera's transaction writeset
(wsrep_append_keys()). However, for LOAD DATA, this got skipped
if binary logging was disabled or it was non-ROW based.
As a result, while the updates from LOAD DATA on non-partitioned
tables replicated fine as wsrep implicitly enables binary logging
(if not enabled, explicitly), the same did not work on partitioned
tables as for partitioned tables the binary logging gets disabled
temporarily (ha_partition::write_row()).

Fixed by removing the unwanted conditions from the check.
Also backported some changes from 10.0-galera to make sure
wsrep_load_data_splitting affects LOAD DATA commands only.

(Additional fix in 10.0-galera branch)
THD's lex->definer initially holds "*current_user" for
CURRENT_USER(). Use get_current_user() to get the real
current user.

(Additional fixes in 10.0-galera branch)
* Reset THD's PS members before returning when node is
not ready.
* Update galera_suspend_slave.test

In galera cluster, when myisam replication is enabled
(wsrep_replicate_myisam=ON), DML statements are replicated
in open_tables(). However, in case of prepared statements,
for an INSERT, open_tables() gets invoked twice. Once for
COM_STMT_PREPARE (to validate and prepare INSERT) and later
for COM_STMT_EXECUTE. As a result, the command gets replicated
twice. Same happens for REPLACE, UPDATE and DELETE commands.
Fixed by adding a check to not replicate during 'prepare'
phase. Also changed the order of conditions to make it more
efficient. Lastly, in order to support wsrep_dirty_reads, made
changes to allow COM_STMT_XXX commands to continue past initial
check even when wsrep is not ready.

RENAME TABLE, unlike other DDLs, was getting replicated before
the access check was performed. As a result, the command could
get get replicated and thus executed on other nodes, even if it
fails on the originating node due to permission issues. Fixed by
moving the logic to check user privileges before replicating the
command.

Added logic to replicate ALTER TABLE EXCHANGE PARTITION to other nodes
in the cluster.

5.5 without InnoDB/XtraDB changes

5.5 with our InnoDB changes

This bug is essentially another variant of MDEV-7458.

If a transaction conflict caused a deadlock kill of T2 in record_gtid()
during commit, the code would do a rollback _before_ running
rgi->unmark_start_commit(). This creates a race where following transactions
could start too early (before T2 has completed its transaction retry). This
in turn could lead to replication failure, if there was a conflict that
caused eg. duplicate key error or similar.

The fix is to remove these rollbacks (in Query_log_event::do_apply_event()
and Xid_log_event::do_apply_event(). They seem out-of-place; code in
log_event.cc generally does not roll back on error, this is handled higher
up.

In addition, because of the extreme difficulty of reproducing bugs like
MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to
detect (in debug builds) or prevent (in release builds) similar bugs.
ha_rollback_trans() will now call unmark_start_commit() if needed (and
assert in debug build when a caller does rollback without unmark first).

We also add an extra check for thd->killed() so that we avoid doing
mark_start_commit() if we already have a pending deadlock kill.

And we add a missing unmark_start_commit() call in the error case, found by
the above assertion.

Conflicts:
	client/mysql_upgrade.c
	mysql-test/r/func_misc.result
	mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result
	mysql-test/suite/innodb/r/innodb-fk.result
	mysql-test/t/subselect_sj_mat.test
	sql/item.cc
	sql/item_func.cc
	sql/log.cc
	sql/log_event.cc
	sql/rpl_utility.cc
	sql/slave.cc
	sql/sql_class.cc
	sql/sql_class.h
	sql/sql_select.cc
	storage/innobase/dict/dict0crea.c
	storage/innobase/dict/dict0dict.c
	storage/innobase/handler/ha_innodb.cc
	storage/xtradb/dict/dict0crea.c
	storage/xtradb/dict/dict0dict.c
	storage/xtradb/handler/ha_innodb.cc
	vio/viosslfactories.c