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.

Avoid calling current_thd from thd_kill_level(). This reduces number of
pthread_getspecific() calls from 776 to 354.

Also thd_kill_level(NULL) is not permitted anymore: this saves one condition.

Analysis: Problem was that we did create crypt data for encrypted table but
this new crypt data was not written to page 0. Instead a default crypt data
was written to page 0 at table creation.

Fixed by explicitly writing new crypt data to page 0 after successfull
table creation.

Step 4 (there will be more)

when checking for a flag, use & not ==

* check key version per key id (that is, per tablespace).
* wake encryption thread when a tablespace needs re-encryption

show that two keys can be different if they have different ids
or different versions.

fix encryption of the last partial block

* now really encrypt it, using key and iv
* support the case of very short plaintext (less than one block)
* recommend aes_ctr over aes_cbc, because the former
  doesn't have problems with partial blocks

* don't use do_crypt() for stream cipher AES_CTR
* rename do_crypt to block_crypt to emphasize its specialization

InnoDB: refuse to start if encryption is requested but no
encryption plugin is available