* no --encryption-algorithm option anymore
* encrypt/decrypt methods in the encryption plugin
* ecnrypt/decrypt methods in the encryption_km service
* file_km plugin has --file-key-management-encryption-algorithm
* debug_km always uses aes_cbc
* example_km changes between aes_cbc and aes_ecb for different key versions

because it's going to do more than just key management

only those tests should be disabled in suite.pm that
cannot be disabled from mysqltest files (e.g. when the
server is started with a special command-line option -
unknown option will abort the server before mysqltest
will start its checks).

only one encryption key lookup in most cases instead of three
(has_key, get_key_size, get_key).

numerous issues fixed:
* buffer overflows
* error conditions aren't checked (crash if file doesn't exist)
* accessing random unallocated memory
* hard-coded password
* arbitrary hard-coded key id limit
* incomprehensible error messages (for key_id == 0 it reported
  "The key could not be initialized", for syntax errors the message was
  "Wrong match of the keyID, see the template", for a key id
  larger than hard-coded limit the message was "No asked key", and there
  was an error "Is comment" for a comment).
* tons of small mallocs, many are freed few lines down in the code
* malloc(N) and new char[N] are used both, even in the same function
* redundant memory copies
* pcre - "I can solve it with regular expressions" - with incorrect regexes
* parser context stored in a singleton
* keys are stored as strings and are strlen-ed and hex2bin-ed on every
  get_key() request
* lots of useless code (e.g. sprintf instead of a pointer assignment,
  checking of the file length to read a part of it in a fixed buffer,
  multiplying by sizeof(char) in many places, etc)
* this list is not exhaustive

not an address of some arbitrarily chosen symbol;
not when plugin is successfully loaded (which means - no info
  when plugin->init failed);

in particular, "innodb.innodb-page_encryption,xtradb" should
select these three tests:

innodb.innodb-page_encryption 'cbc,xtradb' [ pass ]  35563
innodb.innodb-page_encryption 'ctr,xtradb' [ pass ]  36858
innodb.innodb-page_encryption 'ecb,xtradb' [ pass ]  36741

and deselect all innodb_plugin tests. This was not the case, because
the %test_combs hash was destructively modified in the loop

* my_aes.h doesn't compile without my_global.h
* typo in a comment
* redundant condition
* if encryption plugin fails, there's no encryption_key_manager
  at plugin deinit time
* encryption plugin tests must run when plugin.so is present,
  not when a plugin is active (otherwise the test will be skipped
  when plugin fails to initialize).

for temporary Aria tables. It can use a faster BLOCK_RECORD

now IVs are always handled internally

and simplify Item_func_aes_encrypt/decrypt

to: different key lengths

* comments
* move my_bytes_to_key() and my_aes_hex2uint() into file_key_management_plugin
* rename HA_INSERT_ORDER -> HA_PRESERVE_INSERT_ORDER
* remove unused variables and declarations
* fix casts
* don't link innodb with pcre
* remove redundant entries from aria's TARGET_LINK_LIBRARIES

they should've been deleted long ago, but weren't

followup

(one generally should not do that, these messages are
printed on every cmake run)

Print r_rows. There is no table tracking for reading from tmp table, yet.

MDEV-7878: innodb_scrub_background fails sporadically in buildbot (Failing assertion: offset > 0 && offset < UNIV_PAGE_SIZE)

Problem was that when encrypted space was flushed page 0 is
also updated but crypt data offset was sometimes not
calculated.

Conflicts:
	mysql-test/suite/rpl/r/rpl_parallel.result
	sql/rpl_parallel.cc

MDEV-7847: "Slave worker thread retried transaction 10 time(s) in vain, giving up", followed by replication hanging

This patch fixes a bug in the error handling in parallel replication, when one
worker thread gets a failure and other worker threads processing later
transactions have to rollback and abort.

The problem was with the lifetime of group_commit_orderer objects (GCOs).
A GCO is freed when we register that its last event group has committed. This
relies on register_wait_for_prior_commit() and wait_for_prior_commit() to
ensure that the fact that T2 has committed implies that any earlier T1 has
also committed, and can thus no longer execute mark_start_commit().

However, in the error case, the code was skipping the
register_wait_for_prior_commit() and wait_for_prior_commit() calls. Thus
commit ordering was not guaranteed, and a GCO could be freed too early. Then a
later mark_start_commit() would reference deallocated GCO, which could lead to
lost wakeup (causing slave threads to hang) or other corruption.

This patch makes also the error case respect commit order. This way, also the
error case gets the GCO lifetime correct, and the hang no longer occurs.

When a transaction in parallel replication needs to retry (eg. because of
deadlock kill), first wait for all prior transactions to commit before doing
the retry. This way, we avoid the retry once again conflicting with a prior
transaction, requiring yet another retry.

Without this patch, we saw "in the wild" that transactions had to be retried
more than 10 times to succeed, which exceeds the default
--slave_transaction_retries value and is in any case undesirable.

(We already do this in 10.1 in "optimistic" parallel replication mode; this
patch just makes the code use the same logic for "conservative" mode (only
mode in 10.0)).

making Item_string::is_cs_specified() virtual instead.