Drop trigger handling was missing from wsrep_can_run_in_toi
in 10.5 for some reason.

Related to 7c2ba9e9: ha_table_exists() is replaced by
dd_frm_type(). ha_table_exists() checked the existence of share and
that succeeded to enter the execution branch of ha_delete_table()
where tdc_remove_table() was called. Now it is skipped because
dd_frm_type() returns TABLE_TYPE_UNKNOWN. Fix it by calling
tdc_remove_table() in this case as well.

A mtr failure in rpl.rpl_mariadb_slave_capability mismatch:

-slave-relay-bin.000005	#	Query	#	#	BEGIN
+slave-relay-bin.000005	#	Query	#	#	set foreign_key_checks=1, check_constraint_checks=1; BEGIN

was fixed by {{80544a58}}, and without any check for {{flags_inited}}
which is a pattern in the sources.

This ticket therefore merely makes sure through an assert that a
relation between the two remain in {{Query_log_event::pack_info}}.

Fix DBUG_ASSERT

MDEV-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying to unlock mutex conn->mta_conn_mutex that wasn't locked at storage/spider/spd_db_conn.cc, line 671

Removed some inine assembly, replaced by code from
https://github.com/intel/soft-crc

Also,replace GCC inline assembly for cpuid in ut0crc32 with __cpuid,
to fix "PIC register clobbered by 'ebx' in 'asm'.
This enables fast CRC32C on 32bit Intel processors with GCC.

In the Microsoft environment, my_atomic requires int32.

build_template_field(): Initialize templ->rec_field_is_prefix
also for indexes on virtual columns. This was caught on 10.5 by
MemorySanitizer as use-of-uninitialized-value in
row_search_with_covering_prefix() when running the test
main.fast_prefix_index_fetch_innodb.

This follows up MDEV-14374, which was filed against MariaDB Server 10.3.
Back then, on a 48-core Qualcomm Centriq 2400, the performance of
delay loops for spinloops was tested both with and without the dummy
compare-and-swap operation, and it was decided to keep the dummy
operation.

On target architectures where nothing special is available (other than
x86 (IA-32, AMD64) or POWER), we perform a dummy compare-and-swap operation.
This is contrary to the idea of the x86 PAUSE instruction and the
__ppc_get_timebase(), which aim to keep the memory bus idle for a while,
to allow other cores to better execute code while a spinloop is waiting
for something to be changed.

On MariaDB Server 10.4 and another implementation of the ARMv8 ISA,
omitting the dummy compare-and-swap improved performance by up to 12%.
So, let us avoid the dummy compare-and-swap on ARM.

For now, we are retaining the dummy compare-and-swap on other ISAs
(such as SPARC, MIPS, S390x, RISC-V) because we do not have any
performance data for them.

Add -Wno-missing-field-initializers for MyRocks and gcc version below 5.0

It was failing on mac-1012-bintar.

commit de942c9f (MDEV-15983)
introduced a race condition that we inadequately fixed in
commit 93b69825 (MDEV-16169).

Because fil_space_t::release() or fil_space_t::acquire() are
not protected by fil_system.mutex like their predecessors,
it is possible that stop_new_ops was set between the time
a thread checked fil_space_t::is_stopping() and invoked
fil_space_t::acquire().

In an execution trace, this happened in fil_system_t::keyrotate_next(),
causing an assertion failure in fil_delete_tablespace()
in the other thread that seeked to stop new operations.

We fix this bug by merging the flag fil_space_t::stop_new_ops
and the reference count fil_space_t::n_pending_ops into a
single word that is only being accessed by atomic memory operations.

fil_space_t::set_stopping(): Accessor for changing the state of
the former stop_new_ops flag.

fil_space_t::acquire(): Return whether the acquisition succeeded.
It would fail between set_stopping(true) and set_stopping(false).

In 10.3 OR REPLACE trigger option is part of create_info.

Passing a null pointer to a nonnull argument is not only undefined
behaviour, but it also grants the compiler the permission to optimize
away further checks whether the pointer is null. GCC -O2 at least
starting with version 8 may do that, potentially causing SIGSEGV.

These problems were caught in a WITH_UBSAN=ON build with the
Bug#7024 test in main.view.

Passing a null pointer to the "%s" argument of a printf-like
function is undefined behaviour. In the GNU libc implementation
of the printf() family of functions, it happens to work.

GCC 10.2.0 would diagnose this with -Wformat-overflow -Og.
In -fsanitize=undefined (WITH_UBSAN=ON) builds, a runtime error
would be generated. In some other builds, GCC 8 or later might infer
that the parameter is nonnull and optimize away further checks whether
the parameter is null, leading to SIGSEGV.

As an additional improvement, let's store string representations of
the numbers using an array uint16[256] instead of char[512].
This allows to use int2store(), which copies two bytes at a time on x86,
instead of copying the two bytes with digits one-by-one.

This change gives an additional 7% to 26% query time reduce for:
    SELECT BENCHMARK(10*1000*1000,CONCAT(TIME'10:20:30'));
    SELECT BENCHMARK(10*1000*1000,CONCAT(TIME'10:20:30.123456'));
    SELECT BENCHMARK(10*1000*1000,CONCAT(DATE'2001-01-01'));
    SELECT BENCHMARK(10*1000*1000,CONCAT(TIMESTAMP'2001-01-01 10:20:30'));
    SELECT BENCHMARK(10*1000*1000,CONCAT(TIMESTAMP'2001-01-01 10:20:30.123456'));

The total time reduce (part1 + part2) is now between 15% to 38%
for these queries.

During insertion of clustered index, InnoDB does the check for foreign key
constraints. Problem is that it uses the clustered index entry to search
indexes of referenced tables and it could lead to unexpected result
when there is no foreign index.

Solution:
========
  Rebuild the tuple based on foreign column names before searching it
on reference index when there is no foreign index.

Backporting fixes for:

MDEV-22317: SIGSEGV in my_free/delete_dynamic in optimized builds (ARIA)
  Backported following commits from: 10.5.3
  commit 77e1b0c3 -- Post push fix.
  commit 2e6b21be

MDEV-22059: MSAN report at replicate_ignore_table_grant
  Backported following  commits from: 10.5.4
  commit 840fb495

Build failure was:
storage/innobase/os/os0proc.cc:144:3: error: use of undeclared identifier 'MEM_UNDEFINED'

                MEM_UNDEFINED(ptr, size);

Assumed to be introduced in MDEV-20377
commit: c36834c8

This also fixes MDEV-20464.

The InnoDB index fields store bytes, not characters.
Remove some unnecessary conversions from characters to bytes.

This also fixes MDEV-20422 and the wrong-result bug MDEV-12486.

Add a proper error handling of innobase_get_computed_value results in
row_upd_store_row/row_upd_store_v_row.

Also add an assertion in row_vers_build_clust_v_col to fail during row
purge.
Add one more assertion in row_sel_sec_rec_is_for_clust_rec for possible
future catches.

The problem was in improper error handling behavior in
`row_upd_build_difference_binary`:
`innobase_free_row_for_vcol` wasn't called.

To eliminate this problem in all potential places, a refactoring has been
made:
* class ib_vcol_row is added. It owns VCOL_STORAGE and heap and maintains
 it in RAII manner
* all innobase_allocate_row_for_vcol/innobase_free_row_for_vcol pairs are
 substituted
 with ib_vcol_row usage
* row_merge_buf_add is only left untouched because it doesn't own vheap
 passed as an argument
* innobase_allocate_row_for_vcol does not allocate VCOL_STORAGE anymore and
 accepts it as an argument -- this reduces a number of memory allocations
 * move rec_printer out of `#ifndef DBUG_OFF` and mark it cold