Conversion of a subquery to a semi-join is blocked when we have an
IN subquery predicate in the on_expr of an outer join. Currently this
scenario is handled but the cases when an IN subquery predicate is wrapped
inside a Item_in_optimizer item then this blocking is not done.

Detection of first execution of PS fixed.
More debug info.

For the query having an IN subquery with no tables, we were converting the subquery with an expression between
the left part and the select list of the subquery . This can give incorrect results when we have a condition
in the subquery with a dual table (as this is treated as a no table).

The fix is that we don't do this conversion when we have conds in the subquery with a dual table.

mem_heap_create_block(): Poison the payload area until
mem_heap_alloc() unpoisons it.

Learn both valgrind and asan to catch this bug:

  mem_heap_t* heap = mem_heap_create(1024);
  byte* p = reinterpret_cast<byte*>(heap) + sizeof(mem_heap_t);
  *p = 123;

Overflows of the last allocation in a block will be catched too.

mem_heap_create_block(): poison newly allocated memory

MDEV-6736: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ in WHERE and
           HAVING, ORDER BY, materialization+semijoin

During cleanup a pointer to the materialised table that was freed was not set to NULL

Backport from 10.2

fts_sync(): If the dict_table_t::to_be_dropped flag is set,
do not "goto begin_sync".

Also, clean up the way how dict_index_t::index_fts_syncing
is cleared.

It looks like this regression was introduced by merging
Oracle Bug #24938374 MYSQL CRASHED AFTER LONG WAIT ON DICT OPERATION LOCK
WHILE SYNCING FTS INDEX
https://github.com/mysql/mysql-server/commit/068f8261d4c1e134965383ff974ddf30c0758f51
from MySQL 5.6.38 into MariaDB 10.0.33, 10.1.29, 10.2.10.
The same hang is present in MySQL 5.7.20.

The issue is that we are creating a materialised table with key of length 0 which is incorrect, we should
disable materialisation for such a case.

MDEV-14648 Restore fix for MySQL BUG#39053 - UNINSTALL PLUGIN does not allow the storage engine to cleanup open connections

ha_close_connection(): Do invoke the method also for plugins
for which UNINSTALL PLUGIN was deferred due to open connections.

use the correct handlerton when looking for TRANSACTIONAL=1 support

MDEV-13748 Assertion `status_var.local_memory_used == 0 || !debug_assert_on_not_freed_memory' failed in virtual THD::~THD after query with INTERSECT

my_safe_alloca()/my_safe_afree() work as alloca() or malloc()/free()
depending on the memory size to allocate, that is, depending on
reclength here. They only work correctly if reclength doesn't
change in the middle.

lock_trx_release_locks(): Relax a debug assertion to allow
recovered TRX_STATE_COMMITTED_IN_MEMORY transactions.

trx_commit_in_memory(): Add DEBUG_SYNC instrumentation.

trx_undo_insert_cleanup(): Skip persistent changes if innodb_read_only
is set. This should only happen when a recovered committed transaction
would be cleaned up at shutdown.

proper fix replacing the hack from b80fa400

don't confuse length of the data area (reclength) with the
offset to the "deleted" mark.

The update was lost during merge.

Before killing the server, we have to FLUSH TABLES in order to
prevent the corruption of any MyISAM system tables.

PageConverter::adjust_cluster_record(): Instead of writing
the invalid value DB_ROLL_PTR=0, write a value that indicates
a fresh insert, that is, prevents the DB_ROLL_PTR from being
dereferenced in any circumstances.

It can be argued that IMPORT TABLESPACE should actually
update the dict_index_t::trx_id to prevent older transactions
from accessing the table, similar to what I did on table
rebuild in MySQL 5.6.6 in
https://github.com/mysql/mysql-server/commit/03f81a55f221095d397c375afe8a10c8038da339

Use unsigned comparison.

Suppress some messages that are emitted rarely
(when the FIL_PAGE_FILE_FLUSH_LSN of the first page of ibdata1
does not match the latest redo log checkpoint).

Do not unwrap view references to keep table info.
(Row-IN subselect does not unwrap items so it does not need fix)

only do it in EXTRA_DEBUG builds

Whenever one copies an IO_CACHE struct, one must remember to call
setup_io_cache, if not, the IO_CACHE's current_pos and end_pos
self-references will point to the previous struct's memory, which
could go out of scope. Commit 90038693
fixes this problem in a more general fashion by removing the
self-references altogether, but for 5.5 we'll keep the old behaviour.

MDEV-15014 Assertion `m_cache_lock_status == LOCKED_NO_WAIT || m_cache_status == DISABLE_REQUEST' failed in Query_cache::free_cache on startup

The assert guards against not-locked or not-requested query cache
disabling. If during startup we disable query cache, we failed to
request disabling.

        The thd->lex->part_info should be kept intact during PS
        execution. Or the second execution gets that modified part_info.
        Let's modify ths->work_part_info instead.

Item_xml_str_func::fix_fields() used a local "String tmp" as a buffer
for args[1]->val_str(). "tmp" was freed at the end of fix_fields(),
while Items created during my_xpath_parse() still pointed to its fragments.

Adding a new member Item_xml_str_func::m_xpath_query and store the result
of args[1]->val_str() into it.