MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2
by commit fec844ac
which introduced some Galera-specific conditions that were being
evaluated even if the write-set replication was not enabled.

MDEV-13246 Stale rows despite ON DELETE CASCADE constraint
is a correctness regression that was introduced by the same commit.

Especially the subcondition
	!(parent && que_node_get_type(parent) == QUE_NODE_UPDATE)
which is equivalent to
	!parent || que_node_get_type(parent) != QUE_NODE_UPDATE
makes little sense. If parent==NULL, the evaluation would proceed to the
std::find() expression, which would dereference parent. Because no SIGSEGV
was observed related to this, we can conclude that parent!=NULL always
holds. But then, the condition would be equivalent to
	que_node_get_type(parent) != QUE_NODE_UPDATE
which would not make sense either, because the std::find() expression
is actually assuming the opposite when casting parent to upd_node_t*.

It looks like this condition never worked properly, or that
it was never properly tested, or both.

wsrep_must_process_fk(): Helper function to check if FOREIGN KEY
constraints need to be processed. Only evaluate the costly std::find()
expression when write-set replication is enabled.

Also, rely on operator<<(std::ostream&, const id_name_t&) and
operator<<(std::ostream&, const table_name_t&) for pretty-printing
index and table names.

row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition.
This is applying part of "Galera MW-369 FK fixes"
https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52
that is described by the following part of the commit comment:
    additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has
    BF, essentially is applier or replaying
    This FK check would be needed only for populating parent row FK keys
    in write set, so no use for appliers

trx_set_rw_mode(): Check the flag high_level_read_only instead
of testing srv_force_recovery (innodb_force_recovery) directly.
There is no need to prevent the creation of read-write transactions
if innodb_force_recovery=3 is used. Yes, in that mode any recovered
incomplete transactions will not be rolled back, but these transactions
will continue to hold locks on the records that they have modified.
If the new read-write transactions hit conflicts with already existing
(possibly recovered) transactions, the lock wait timeout mechanism
will work just fine.

Install mtr and mysql-test-run symlinks in case of the out-of-source
build. This was broken in c872b100

Make test result stable

collateral changes:
* remove a test from innodb_virtual_basic that is already present in
  gcol_keys_innodb
* set thd->abort_on_warning for inplace alter, just like it's set
  for copy_data_between_tables - to have warnings converted into
  errors identically in all alter algorithms
* don't ignore errors in TABLE::update_virtual_field

don't allocate memory on thd->mem_root in every fix_fields(),
do it once and reuse.

doing SYSVAR_AUTOSIZE() because of back_log > max_connections
enabled "autosized" flag, and that made IS_SYSVAR_AUTOSIZE()
true, which triggered the second SYSVAR_AUTOSIZE.

Remove back_log <= max_connections limit, back_log
doesn't *always* have to be smaller than max_connections.

make JSON an alias for LONGTEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_bin

(same collation that item_jsonfunc.cc is using internally)

SQL Standard behavior for DROP COLUMN xxx RESTRICT:
* If a constraint (UNIQUE or CHECK) uses only the dropped column,
  it's automatically dropped too. If it uses many columns - an error.

don't allow arbitrary combinations of SIGNED/UNSIGNED/ZEROFILL

let include/restart_mysqld.inc use include/start_mysqld.inc
and include/shutdown_mysqld.inc. Instead of copying their content.

InnoDB: in slow shutodwn mode do not stop purge threads
as long as some connection threads are running

execute queries after purge thread has exited, but the connection
thread hasn't

before c720e68f it used to crash

install all server includes under /usr/include/mysql/server/
and C/C includes under /usr/include/mysql/

CMakeLists.txt - merge mistake, apparently

include/CMakeLists.txt - install from CMAKE_CURRENT_BINARY_DIR.
  Only install from CMAKE_CURRENT_SOURCE_DIR, if it's different
  from CMAKE_CURRENT_BINARY_DIR

mysql-test/CMakeLists.txt - INSTALL_MYSQL_TEST() macro installs
  everything, no need to install mtr separately once again

mysql-test/lib/My/SafeProcess/CMakeLists.txt
  MYSQL_ADD_EXECUTABLE includes INSTALL

sql-bench/CMakeLists.txt
  list files explicitly. don't install garbage, don't process 'foo'
  and 'foo.sh' separately, it's only one file to install, not two.

xtrabackup_copy_log(): Use a 64-bit bitmask (lsn_t), not 32-bit (int).

        JSON_EXTRACT behaves specifically in the comparison,
        so we have to implement specific method for that in
        Arg_comparator.

buf_page_io_complete(): Do not test bpage for NULL, because
it is declared (and always passed) as nonnull.

buf_flush_batch(): Remove the constant local variable count=0.

fil_ibd_load(): Use magic comment to suppress -Wimplicit-fallthrough.

ut_stage_alter_t::inc(ulint): Disable references to an unused parameter.

lock_queue_validate(), sync_array_find_thread(), rbt_check_ordering():
Define only in debug builds.

The bug is result adding ability to have derived tables inside views.
Fixed checks should be a switch between view/derived or select derived and information schema.

Only a relevant subset of the InnoDB changes was merged.
In particular, two follow-up bug fixes for the bugs that
were introduced in 5.7.18 but not MariaDB 10.2.7 were omitted.
Because MariaDB 10.2.7 omitted the risky change

Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
APPLIED BY UNCOMMITTED ROWS

we do not need the follow-up fixes that were introduced in
MySQL 5.6.37 and MySQL 5.7.19:

Bug#25175249 ASSERTION: (TEMPL->IS_VIRTUAL && !FIELD) || ...
Bug#25793677 INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN

Analysis:
=========
   During alter table rebuild, InnoDB fails to apply concurrent insert log.
If the insert log record is present across the blocks then apply phase
trying to access the next block without fetching it.

Fix:
====
During virtual column parsing, check whether the record is present
across the blocks before accessing the virtual column information.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 16243

Analysis:
========
During alter table rebuild, InnoDB fails to apply concurrent delete log.
Parsing and validation of merge record happens while applying the
log operation on a table. Validation goes wrong for the virtual column.
Validation assumes that virtual column information can't be the end
of the merge record end.

Fix:
====
Virtual column information in the merge record can be end of the merge
record. Virtual column information is written at the end for
row_log_table_delete().

Reviewed-by: Satya Bodapati<satya.bodapati@oracle.com>
RB: 16155

The test is for a bug that was introduced in MySQL 5.7.18
but not MariaDB 10.2, because MariaDB did not merge the change
that was considered incomplete and too risky for a GA release:

Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
APPLIED BY UNCOMMITTED ROWS

So, we are only merging the test changes from the bug fix in MySQL 5.7.19,
not any code changes:

commit 4f86aca37d551cc756d9187ec901f8c4a68a0543
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Wed Apr 26 11:10:41 2017 +0530

    Bug #25793677   INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN

MariaDB 10.2 never contained the Oracle change

Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE
INDEX APPLIED BY UNCOMMITTED ROWS

because it was considered risky for a GA release and incomplete.
Remove the references that were added when merging MySQL 5.6.36
to MariaDB 10.0.31, 10.1.24, and 10.2.7.

Analysis:
========

(1) During TRUNCATE of file_per_table tablespace, dict_operation_lock is
released before eviction of dirty pages of a tablespace from the buffer
pool. After eviction, we try to re-acquire
dict_operation_lock (higher level latch) but we already hold lower
level latch (index->lock). This causes latch order violation

(2) Deadlock issue is present if child table is being truncated and it
holds index lock. At the same time, cascade dml happens and it took
dict_operation_lock and waiting for index lock.

Fix:
====
1) Release the indexes lock before releasing the dict operation lock.

2) Ignore the cascading dml operation on the parent table, for the
cascading foreign key, if the child table is truncated or if it is
in the process of being truncated.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
Reviewed-by: Kevin Lewis <kevin.lewis@oracle.com>
RB: 16122

Issue
====
The issue is that the info message that InnoDB prints when a table
is created with a reference which doesn't exist fills up the log as
it's printed for every insert when foreign_key_checks is disabled.

Fix
===
The fix is to display the message only if foreign_key_checks is
enabled.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>

Problem:
=======
   Offsets allocates memory from row_heap even for deleted row
traversal during table rebuild.

Solution:
=========
  Empty the row_heap even for deleted record. So that
offsets don't allocate memory everytime.
Reviewed-by: Jimmy Yang <jimmy.yang@oracle.com>
RB: 15694

Cherry-pick the commit from MySQL 5.7.19, and adapt the test case:

commit 45c933ac19c73a3e9c756a87ee1ba18ba1ac564c
Author: Aakanksha Verma <aakanksha.verma@oracle.com>
Date:   Tue Mar 21 10:31:43 2017 +0530

    Bug #25189192   ERRORS WHEN RESTARTING MYSQL AFTER RENAME TABLE.

    PROBLEM

    While renaming table innodb doesn't update the InnoDB Dictionary table
    INNODB_SYS_DATAFILES incase there is change in database while doing
    rename table. Hence on a restart the server log shows error that it
    couldnt find table with old path before rename which has actually been
    renamed. So the errors would only vanish if we update the system
    tablespace

    FIX

    Update the innodb dictionary table with new path in the case there is
    not a change in the table but the database holding the table as well.

    Reviewed-by: Jimmy Yang<Jimmy.Yang@oracle.com>
    RB: 15751