10.0 part of the fix

update main.delayed test after 38b89a61
ALTER TABLE ... COMMENT is no longer blocking,
use a different ALTER TABLE variant.

Fixed more cases for MDEV-6282

don't strcpy a string to itself

s/Execute/Query/ to account for --ps-protocol

typo. the code was not matching the comment

fix a buffer overflow in extension_based_table_discovery
(that only happens in debug builds)

Remove Linuxism. 

Works fine with a POSIX-compat shell

don't crash in debug builds. issue an error message on corrupt event

MariaDB-server-10.1 should obsolete MariaDB-Galera-server

when creating shadow nullable fields, preserve all
original field flags (because we swap flags
back and forth in not_null_fields_have_null_values())

in particular, don't do ExternalProject_Add()
that starts creating build directories for a disabled
plugin

MDEV-9739 Assertion `m_status == DA_ERROR || m_status == DA_OK' failed in Diagnostics_area::message() ; connect.xml* tests fail in buildbot

don't fail if cracklib_password_check is statically compiled in

Fix incorrectly merged files on innodb_plugin.

Fixed printing integer constant in the ORDER clause (MySQL solution)
Removed workaround for double resolving counter in the ORDER.

5.5 part of the fix

MDEV-9653 Assertion `length || !scale' failed in uint my_decimal_length_to_precision(uint, uint, bool)
MDEV-9752 Wrong data type for COALEASCE(?,1) in prepared statements

In RHEL7/RHEL7.1 libcrack behavior seem to have been modified so that
"foobar" password is considered bad (due to descending "ba") earlier than
expected. For details google for cracklib-2.9.0-simplistic.patch.

Adjusted affected passwords not to have descending and ascending sequences.

Analysis:

-- InnoDB has n (>0) redo-log files.
-- In the first page of redo-log there is 2 checkpoint records on fixed location (checkpoint is not encrypted)
-- On every checkpoint record there is up to 5 crypt_keys containing the keys used for encryption/decryption
-- On crash recovery we read all checkpoints on every file
-- Recovery starts by reading from the latest checkpoint forward
-- Problem is that latest checkpoint might not always contain the key we need to decrypt all the
   redo-log blocks (see MDEV-9422 for one example)
-- Furthermore, there is no way to identify is the log block corrupted or encrypted

For example checkpoint can contain following keys :

write chk: 4 [ chk key ]: [ 5 1 ] [ 4 1 ] [ 3 1 ] [ 2 1 ] [ 1 1 ]

so over time we could have a checkpoint

write chk: 13 [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ]

killall -9 mysqld causes crash recovery and on crash recovery we read as
many checkpoints as there is log files, e.g.

read [ chk key ]: [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]
read [ chk key ]: [ 14 1 ] [ 13 1 ] [ 12 1 ] [ 11 1 ] [ 10 1 ] [ 9 1 ]

This is problematic, as we could still scan log blocks e.g. from checkpoint 4 and we do
not know anymore the correct key.

CRYPT INFO: for checkpoint 14 search 4
CRYPT INFO: for checkpoint 13 search 4
CRYPT INFO: for checkpoint 12 search 4
CRYPT INFO: for checkpoint 11 search 4
CRYPT INFO: for checkpoint 10 search 4
CRYPT INFO: for checkpoint 9 search 4 (NOTE: NOT FOUND)

For every checkpoint, code generated a new encrypted key based on key
from encryption plugin and random numbers. Only random numbers are
stored on checkpoint.

Fix: Generate only one key for every log file. If checkpoint contains only
one key, use that key to encrypt/decrypt all log blocks. If checkpoint
contains more than one key (this is case for databases created
using MariaDB server version 10.1.0 - 10.1.12 if log encryption was
used). If looked checkpoint_no is found from keys on checkpoint we use
that key to decrypt the log block. For encryption we use always the
first key. If the looked checkpoint_no is not found from keys on checkpoint
we use the first key.

Modified code also so that if log is not encrypted, we do not generate
any empty keys. If we have a log block and no keys is found from
checkpoint we assume that log block is unencrypted. Log corruption or
missing keys is found by comparing log block checksums. If we have
a keys but current log block checksum is correct we again assume
log block to be unencrypted. This is because current implementation
stores checksum only before encryption and new checksum after
encryption but before disk write is not stored anywhere.

don't allocate all the stack, leave some stack for
function calls.

To test I added the following line:
  alloca_size = available_stack_size() - X
at X=4096 or less mysqld crashed, at 8192 mtr test passed.

remove erroneous free() call

Removing a wrong ASSERT. Item_sum_field now uses the inherited
Item::get_tmp_table_field().

Update sponsors

MDEV-9699: power8 crc32: Per the PPC64 ABI, v20-v31 are non-volatile registers