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

chomp the secret, as read from the file. remove trailing
CR and LF bytes.

applied upstream patch

remove few tests for variables that never existed (merge error)

Added THD argument to select_result and all derivative classes.
This reduces number of pthread_getspecific calls from 796 to 776 per OLTP RO
transaction.

Recording --ps and --embedded tests (a postfix for MDEV-7807)

Removed yet more mysql_reset_thd_for_next_command(). Call
THD::reset_for_next_command() directly instead.

sql_alloc() has additional costs compared to direct mem_root allocation:
- function call: it is defined in a separate translation unit and can't be
  inlined
- it needs to call pthread_getspecific() to get THD::mem_root

It is called dozens of times implicitely at least by:
- List<>::push_back()
- List<>::push_front()
- new (for Sql_alloc derived classes)
- sql_memdup()

Replaced lots of implicit sql_alloc() calls with direct mem_root allocation,
passing through THD pointer whenever it is needed.

Number of sql_alloc() calls reduced 345 -> 41 per OLTP RO transaction.
pthread_getspecific() overhead dropped 0.76 -> 0.59
sql_alloc() overhed dropped 0.25 -> 0.06

delete_dynamic() was called 9-11x per OLTP RO query + 3x per BEGIN/COMMIT.

3 calls were performed by LEX_MASTER_INFO. Added condition to call those only
for CHANGE MASTER.

1 call was performed by lock_table_names()/Hash_set/my_hash_free(). Hash_set was
supposed to be used for DDL and LOCK TABLES to gather database names, while it
was initialized/freed for DML too. In fact Hash_set didn't do any useful job
here. Hash_set was removed and MDL requests are now added directly to the list.

The rest 5-7 calls are done by optimizer, mostly by Explain_query and friends.
Since dynamic arrays are used in most cases, they can hardly be optimized.

my_hash_free() overhead dropped 0.02 -> out of radar.
delete_dynamic() overhead dropped 0.12 -> 0.04.

Removed mysql_reset_thd_for_next_command(). Call THD::reset_for_next_command()
directly instead.

mysql_reset_thd_for_next_command() overhead dropped 0.04% -> out of radar.
THD::reset_for_next_command() overhead didn't increase.

PROFILING::start_new_query() optimizations:
- no need to check "current": added assertion instead
- "enabled" now means "is enabled currently" instead of "was enabled at query
  start". Old meaning was useless, new meaning echoes OPTION_PROFILING so
  that start_new_query() can be defined in sql_profile.h.
- remnants of start_new_query() moved to sql_profile.h so it can be inlined

PROFILING::start_new_query() overhead dropped 0.08% -> out of radar.

PROFILING::set_query_source() optimizations:
- no need to check "enabled": !enabled && current is impossible
- remnants of set_query_source() moved to sql_profile.h so it can be inlined

PROFILING::set_query_source() overhead dropped 0.02% -> out of radar.

PROFILING::finish_current_query() optimizations:
- moved "current" check out to sql_profile.h so it can be inlined

PROFILING::finish_current_query() overhead dropped 0.10% -> out of radar.