- Changed replaying to always allocate a separate THD object
  for applying log events. This is to avoid tampering original
  THD state during replay process.
- Return success from sp_instr_stmt::exec_core() if replaying
  succeeds.
- Do not push warnings/errors into diagnostics area if the
  transaction must be replayed. This is to avoid reporting
  transient errors to the client.

Added two tests galera_sp_bf_abort, galera_sp_insert_parallel.
Wsrep-lib position updated.

	deleted:    mysql-test/suite/galera/r/MW-86.result
	deleted:    mysql-test/suite/galera/r/mysql-wsrep#216.result
	modified:   mysql-test/suite/galera/t/GCF-1081.test
	modified:   mysql-test/suite/galera_3nodes_sr/r/GCF-832.result
	modified:   mysql-test/suite/galera_3nodes_sr/t/GCF-810A.test
	modified:   mysql-test/suite/galera_3nodes_sr/t/GCF-810B.test
	modified:   mysql-test/suite/galera_3nodes_sr/t/GCF-810C.test
	modified:   mysql-test/suite/galera_3nodes_sr/t/GCF-832.test
	modified:   mysql-test/suite/galera_sr/r/mysql-wsrep-features#35.result
	modified:   mysql-test/suite/galera_sr/t/mysql-wsrep-features#35.test

If SUBS_IN_TO_EXISTS strategy has been chosen for a subquery then
additional conditions are injected into WHERE/ON/HAVING of this subquery
and it may happen that test_quick_select() invoked from
JOIN::make_range_rowid_filters() discovers impossible range. This
must be checked.

Temporary table is defined with the view field in HAVING.
Item_direct_view_ref for this field is dropped and that causes error.

To fix it Item_direct_view_ref::remove_item_direct_ref() is added.

The bug occurs because of the wrong pushdown of constant function
defined with subquery from HAVING into WHERE. Subqueries can't be
pushed into WHERE.

To fix it with_subquery() call is added to check if the function contains
subquery.

A syntax error was reported for any INSERT statement with explicit
partition selection it if i used a column list.
Fixed by saving the parsing place before parsing the clause for explicit
partition selection and restoring it when the clause has been parsed.

    This bug is caused by pushdown from HAVING into WHERE.
    It appears because condition that is pushed wasn't fixed.

    It is also discovered that condition pushdown from HAVING into
    WHERE is done wrong. There is no need to build clones for some
    conditions that can be pushed. They can be simply moved from HAVING
    into WHERE without cloning.
    build_pushable_cond_for_having_pushdown(),
    remove_pushed_top_conjuncts_for_having() methods are changed.

    It is found that there is no transformation made for fields of
    pushed condition.
    field_transformer_for_having_pushdown transformer is added.

    New tests are added. Some comments are changed.

Fixed by adding more rows to a table

Other things:
- Speed up index_merge tests 20% by adding begin/commit around loops that
  generated rows.

Normally, InnoDB will create temporary table names of the form
#sql-ibNNNN, and with innodb_safe_truncate=OFF, #sql-ibNNNN-MMMM.

If InnoDB crash recovery was needed, the InnoDB function srv_start()
would invoke extra validation, reading something from every InnoDB
data file. This should be unnecessary now that MDEV-14717 made
RENAME operations crash-safe inside InnoDB (which can be
disabled in MariaDB 10.2 by setting innodb_safe_truncate=OFF).

dict_check_sys_tables(): Skip tables that would be dropped by
row_mysql_drop_garbage_tables(). Perform extra validation only
if innodb_safe_truncate=OFF, innodb_force_recovery=0 and
crash recovery was needed.

dict_load_table_one(): Validate the root page of the table.
In this way, we can deny access to corrupted or mismatching tables
not only after crash recovery, but also after a clean shutdown.

Just rename index in data dictionary and in InnoDB cache when it's possible.
Introduce ALTER_INDEX_RENAME for that purpose so that engines can optimize
such operation.

Unused code between macro MYSQL_RENAME_INDEX was removed.

compare_keys_but_name(): compare index definitions except for index names

Alter_inplace_info::rename_keys:
ha_innobase_inplace_ctx::rename_keys: vector of rename indexes

fill_alter_inplace_info():: fills Alter_inplace_info::rename_keys

For some reason, GCC 8 did not issue warnings for all such comparisons.

Moved rea_create_table() to the sole caller.

Also ha_create_partitioning_metadata(CHF_CREATE_FLAG) does cleanup on
error now.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.

Do not register intermediate tables created by inplace ALTER TABLE in
THD::temporary_tables.

Regular ALTER TABLE doesn't create .frm for temporary and discoverable
tables anymore. For inplace ALTER TABLE moved .frm creation to
create_table_for_inplace_alter().

Removed open_in_engine argument of create_and_open_tmp_table() and
open_temporary_table(): it became unused after this patch.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.

row_is_mysql_tmp_table_name(): Replaced with
dict_table_t::is_temporary_name() and table_name_t::is_temporary().

table_name_t: Add constructors.

This check was introduced in 602a2225 and then became redundant in ad1553e,
where we attempt to open a table even for non-copy algorithms.

Added missing test case from 602a2225.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.

It is used only with persistent tables, so remove path argument, which
was introduced in 9594107f and became useless after ce6a63ec.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.

CREATE TEMPORARY TABLE locks SE plugin 6 times. 5 of these locks are
released by the end of the statement. And only 1 acquired by
init_from_binary_frm_image() / plugin_lock() remains.

The lock removed in this patch was clearly redundant.

Part of MDEV-17805 - Remove InnoDB cache for temporary tables.

In MariaDB, InnoDB tables will always contain DATA_N_SYS_COLS = 3
columns, 2 or 3 of which are present in the clustered index.
We remove the predicate that was added in MySQL 5.7 as part of WL#7682.

Provide a dummy definition of WSREP_NNULL.
This was broken in commit b896f60a.

MDEV-18820 Assertion `lock_table_has(trx, index->table, LOCK_IX)' failed in lock_rec_insert_check_and_lock upon INSERT into table with blob key

Don't Ignore Any error during index lookup, And throw duplicate key error
only if error is HA_ERR_FOUND_DUPP_KEY