* mysqld_safe: Since wsrep_on variable is mandatory in 10.1, skip wsrep
position recovery if its OFF.
* mysqld: Remove "-wsrep" from server version
* mysqld: Remove wsrep patch version from @@version_comment
* mysqld: Introduce @@wsrep_patch_version

Do not reset timer inside stored procedures and functions.

that was apparently lost in 20c23048:

  commit 20c23048
  Author: Jan Lindström <jan.lindstrom@mariadb.com>
  Date:   Sun May 17 14:14:16 2015 +0300

      MDEV-8164: Server crashes in pfs_mutex_enter_func after fil_crypt_is_closing

This also reverts 8635c4b4:

  commit 8635c4b4
  Author: Jan Lindström <jan.lindstrom@mariadb.com>
  Date:   Thu May 21 11:02:03 2015 +0300

      Fix test failure.

as it's not used by the other Item_bool_func2 descendands.

Forgot that echo will also expand variables and path might be different.

Step #8: Adding get_mm_tree() in Item_func, Item_func_between,
Item_func_in, Item_equal. This removes one virtual call item->type()
in queries like:
  SELECT * FROM t1 WHERE c BETWEEN const1 AND const2;
  SELECT * FROM t1 WHERE c>const;
  SELECT * FROM t1 WHERE c IN (const_list);

Analysis: Problem was that encryption was skipped.

Fixed by making sure that tables with ENCRYPTED=YES are encrypted.

Analysis: Problem was that used compression method needs to be stored
to the page.

Fixed by storing compression method after key_version to the page.

Step #7 (mostly preparatory for the next step #8):
Splitting the function get_mm_parts() into a virtual method in Item.
This changes a virtual call for item->type() into a virtual call for item->get_mm_tree(),
but also *removes* one virtual call Item_cond::functype(), which used to distinguish
between COND_AND_FUNC vs COND_OR_FUNC.

MDEV-8213: encryption.encryption_force, encryption.encrypt_and_grep fail with valgrind warnings (Invalid read)

Analysis: Problem was that code used old pointer.

Fixed by using correct pointer.

When the slave processes the master restart format_description event,
parallel replication needs to complete any prior events before processing
the restart event (which closes temporary tables and such stuff).

This happens in wait_for_workers_idle(), however it was not waiting long
enough. The wait was using wait_for_prior_commit(), but at that points table
can still be open. This lead to assertion in this case.

So change wait_for_workers_idle() to wait until all worker threads have
reached finish_event_group(), at which point all tables should have been
closed.

- Changing Comp_creator::create() and create_swap() to return
  Item_bool_rowready_func2 instead of Item_bool_func2, as they
  can never return neither Item_func_like nor Item_func_xor

- Changing the first argument of Comp_create::create() and create_swap()
  from THD to MEM_ROOT, so the method implementations can now reside in
  item_cmpfunc.h instead of item_cmpfunc.cc and thus make the code slightly
  easier to read.

Problem is that when encryption/decryption is marked done on memory
cache, dirty pages might not be physically written.

Fixed by adding sleep on test.

MDEV-8195: InnoDB: Error: trying to access tablespace 11262 page no. 7, InnoDB: but the tablespace does not exist or is just being dropped.

Analysis: Problem was that we did try to read from tablespace
that was being dropped.

Fixed by introducing a new function to find a tablespace only
if it is not being dropped currently and adding this check
before trying to read pages from tablespace.

Analysis: At fil_spage_get_space there is small change that space
is found from tablespace list but we have not yet created node
for it (and added it to space->chain) and as we hold fil_system
mutex here fil_node_create can't continue.

Fixed by allowing UT_LIST_GET_LEN(space->chain) == 0|| 1 and
introducint two new functions that access filespace list
and before returning space check that node is also created.

Make sure that when we publish the crypt_data we access the
memory cache of the tablespace crypt_data. Make sure that
crypt_data is stored whenever it is really needed.

All this is not yet enough in my opinion because:

sql/encryption.cc has DBUG_ASSERT(scheme->type == 1) i.e.
crypt_data->type == CRYPT_SCHEME_1

However, for InnoDB point of view we have global crypt_data
for every tablespace. When we change variables on crypt_data
we take mutex. However, when we use crypt_data for
encryption/decryption we use pointer to this global
structure and no mutex to protect against changes on
crypt_data.

Tablespace encryption starts in fil_crypt_start_encrypting_space
from crypt_data that has crypt_data->type = CRYPT_SCHEME_UNENCRYPTED
and later we write page 0 CRYPT_SCHEME_1 and finally whe publish
that to memory cache.

Part 2: detauch service thread.

Part 1: first 2 cases of valgrind complain. context_analysis_only can be used on non-started LEX (opening tables)

obviouse fixes in DBUG and is_lex_started assignment.

The previous commit did not contain the reviewed changes
and introduced a behaviour problem for the explain statement.
This fixes the issue.

When detecting a statement that can make use of ha_delete_all_rows(),
we refrained from running the statement when being presented
with the analyze or explain prefix.

Analysis: Problem was that tablespaces not encrypted might not have
crypt_data stored on disk.

Fixed by always creating crypt_data to memory cache of the tablespace.

MDEV-8138: strange results from encrypt-and-grep test

Analysis: crypt_data->type is not updated correctly on memory
cache. This caused problem with state tranfer on
encrypted => unencrypted => encrypted.

Fixed by updating memory cache of crypt_data->type correctly based on
current srv_encrypt_tables value to either CRYPT_SCHEME_1 or
CRYPT_SCHEME_UNENCRYPTED.

that is, after

  commit dd8f9319
  Author: Sergei Golubchik <serg@mariadb.org>
  Date:   Fri Apr 10 02:36:54 2015 +0200

    be less annoying about sysvar-based table attributes
    do not *always* add them to the create table definition,
    but only when a sysvar value is different from a default.
    also, when adding them - don't quote numbers

that is, after

  commit 2300fe2e
  Author: Sergei Golubchik <serg@mariadb.org>
  Date:   Wed May 13 21:57:24 2015 +0200

      Identical key derivation code in XtraDB/InnoDB/Aria

"use after free" bug, when a thread replaces space->crypt_data
and frees the old crypt_data object while it's being used
by another thread.

MDEV-8158 InnoDB: Failing assertion: new_state->key_version != ENCRYPTION_KEY_VERSION_INVALID on dynamic change of encryption variables

don't allow to enable srv_encrypt_tables if no
encryption plugin is loaded

encrypting 0 byte string *is* possible

to simplify various checks, set crypt_data->key_id even
for not encrypted tablespaces

* Extract it into the "encryption_scheme" service.
* Make these engines to use the service, remove duplicate code.
* Change MY_AES_xxx error codes, to return them safely
  from encryption_scheme_encrypt/decrypt without conflicting
  with ENCRYPTION_SCHEME_KEY_INVALID error

Step#5: changing the function remove_eq_conds() into a virtual method in Item.
It removes 6 virtual calls for Item_func::type(), and adds only 2
virtual calls for Item***::remove_eq_conds().

This is an addition to original patch. Embedded server does extra calls of
PROFILING::start_new_query() and PROFILING::finish_current_query(), which
cause DBUG_ASSERT(!current) failure.

Removed these extra calls: dispatch_command() does all needed job.