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.

Attempting to kill query owned by different user now returns better error:
"You are not owner of query N" instead of "You are not owner of thread N".

Analysis: In fil_crypt_space_needs_rotation we first make sure that
tablespace is found and then separately that it is normal tablespace.
Thus, tablespace could be dropped between these two functions calls.

Fix: If space is not found from fil_system return tablespace type
ULINT_UNDEFINED and naturally do not continue rotating space.

Analysis: There is race between drop table and encryption threads that
could cause encryption thread to enter mutex that has been already
released.

Fix: When destroying crypt_data first enter the mutex and set crypt data
unavailable, then release the memory and clean up the data. This should
make the race more unprobable. Additionally, added big_test for
create_or_replace as it could fail testcase timeout
if you have slow I/O (tested that testcase passes with --mem).

as a workaround until the bug is fixed
don't run mroonga tests in --embedded mode by default

WARN_DEPRECATED_NO_REPLACEMENT(NULL, ...) was causing a warning,
because it expanded into NULL->variables.errmsgs[...]

because the actual merge was already done in
dced5146
as a patch

In non-wsrep builds, wsrep_running_threads should be defined to (0).

The version in sysvars_innodb,32bit,xtradb.rdiff was not updated

--gtid-ignore-duplicates was comparing sequence numbers as 32-bit, so
after 2**32 transactions things would start to fail.

The test did not wait until the server shuts down

Problem was that for queries of type:

select rand() r, rand()  p, rand() = rand() from a having r = p

The optimizer thought that r = p was same as rand() = rand() and this would always be true.

The problem was that when testing if two expressions are equal, we didn't take into account no determinstic functions.

The fix is to not compare non deterministic functions as equal.

Other things:
- Avoid calling init_and_set_log_file_name() when opening binary log.
- Remove newlines early when reading from index file.
- Ensure that reset_logs() will work even if thd is 0 (Can happen on startup)
- Added thd to sart_slave_threads() for better error handling.

Enable replication of GRANT/REVOKE ROLE commands across
galera nodes.

Cleanups, fixed warnings from valgrind, fixed failing tests (because on changes in WSREP initialization)

This should not have caused any notable errors in most cases.

After fix, we are not using keys to solve MIN/MAX if the string used for comparision is longer thant the column-

Conflicts:
	sql/item_subselect.cc

Fixed also typo in comment

- Cache variables.lc_messages->errmsgs->errmsgs in variables.errmsgs

This gives us 15 byte less code space and 2 memory references for any access to language dependent message,
of which there are 500 in the server..

In some cases NO_ZERO_DATE did not allow datetime values with zero date part
and non-zero time part (e.g. '0000-00-00 10:20:30.123456').
Allowing values of this kind in all known pieces of the code.

Additional changes :
* On startup, do not initialize wsrep if wsrep_on=0.
* On shutdown, stop wsrep replication only if > 0 wsrep
threads are running.