cases.

In key rotation, we must initialize unallocated but previously
initialized pages, so that if encryption is enabled on a table,
all clear-text data for the page will eventually be overwritten.
But we should not rotate keys on pages that were never allocated
after the data file was created.

According to the latching order rules, after acquiring the
tablespace latch, no page latches of previously allocated user pages
may be acquired. So, key rotation should check the page allocation
status after acquiring the page latch, not before. But, the latching
order rules also prohibit accessing pages that were not allocated first,
and then acquiring the tablespace latch. Such behaviour would indeed
result in a deadlock when running the following tests:
encryption.innodb_encryption-page-compression
encryption.innodb-checksum-algorithm

Because the key rotation is accessing potentially unallocated pages, it
cannot reliably check if these pages were allocated. It can only check
the page header. If the page number is zero, we can assume that the
page is unallocated.

fil_crypt_rotate_page(): Detect uninitialized pages by FIL_PAGE_OFFSET.
Page 0 is never encrypted, and on other pages that are initialized,
FIL_PAGE_OFFSET must contain the page number.

fil_crypt_is_page_uninitialized(): Remove. It suffices to check the
page number field in fil_crypt_rotate_page().

prepend enable-named-pipe (windows-only) option in auth_plugin_win.opt
with loose- prefix, to avoid warning on non-Windows.

if plugin_dir is specified. Also, allow to specify protocol (e.g pipe)

srv_undo_tablespaces_init(): In Mariabackup backup mode,
do initialize the array of undo_tablespace_ids[].

Page read could return DB_PAGE_CORRUPTED error that should
be reported and passed to upper layer. In case of unknown
error code we should print both number and string.

This is because they could cause out of storage if run on /dev/shm.

Merged from mysql-wsrep-bugs following:

GCF-1058 MTR test galera.MW-86 fails on repeated runs
Wait for the sync point sync.wsrep_apply_cb to be reached before
executing the test and clearing the debug flag sync.wsrep_apply_cb.

The race scenario:

Intended behavior:
node2: set sync.wsrep_apply_cb in order to start waiting in the background INSERT
node1: INSERT start
node2 (background): INSERT start
node1: INSERT end
node2: send signal to background INSERT: "stop waiting and continue executing"
node2: clear sync.wsrep_apply_cb as no longer needed
node2 (background): consume the signal
node2 (background): INSERT end
node2: DROP TABLE
node2: check no pending signals are left - ok

What happens occasionally (unexpected):
node2: set sync.wsrep_apply_cb in order to start waiting in the background INSERT
node1: INSERT start
node2 (background): INSERT start
node1: INSERT end
// The background INSERT still has _not_ reached the place where it starts
// waiting for the signal:
// DBUG_EXECUTE_IF("sync.wsrep_apply_cb", "now wait_for...");
node2: send signal to background INSERT: "stop waiting and continue executing"
node2: clear sync.wsrep_apply_cb as no longer needed
// The background INSERT reaches DBUG_EXECUTE_IF("sync.wsrep_apply_cb", ...)
// but sync.wsrep_apply_cb has already been cleared and the "wait" code is not
// executed. The signal remains unconsumed.
node2 (background): INSERT end
node2: DROP TABLE
node2: check no pending signals are left - failure, signal.wsrep_apply_cb is
pending (not consumed)

Remove MW-360 test case as it is not intended for MariaDB (uses
MySQL GTID).

Follow-up to original patch: fixing test cases.

also fix innodb

Conflicts:
	mysql-test/include/kill_and_restart_mysqld.inc

Refs: MW-363 * enabling binlog file copying even for binlog files with basename "0" * mtr suite uses binlog files with names: 0.000001, 0.000002.. and so on

MW-378 enabling build with WITH_WSREP=OFF only one fix here, enables build of mysqld however, building embedded server fails in linking phase

Skipping wsrep extra FK checking for applier and replayer threads

Skipping wsrep extra FK checking for applier and replayer threads

Refs: MW-369 * fixed sync point usage in MW-369.inc, which made it impossible to run this test with --repeat option * moved all MW-369*.test tests into MW-369.test file, each as one separate test phase * added two more test phases, in MW-369.test file * tests MW-369A, MW-369B and MW-369C are obsolete after this commit

Refs: MW-369 * changed parent row key type to S(hared), when FK child table is being updated or deleted

Tests MW-369C, MW-369D haven't been recorded yet since the
outcome from the tests is not what is desired.

Refs: MW-369 * added MTR test, which causes a crash in slave applying, due to FK constraint violation * mtr test is not deterministic, but can surface the crash, at least in my laptop

Sync waiting before processing SQLCOM_REPLACE was not necessary given that
this case falls through to processing of SQLCOM_INSERT. In case of
SQLCOM_REPLACE, wsrep_sync_wait would be called twice.