This reverts commit d32ff4ff.
The code around suspending and resuming threads is rather convoluted.
In particular, que_thr_stop_for_mysql() and
lock_wait_suspend_thread() are separated from each other,
and the trx->mutex is being acquired and released multiple times
while a lock wait is being registered. Also, there are multiple
state fields related to lock waits, both in que_thr_t and trx_t.

latch_t: Replace with rw_lock_t. Only the InnoDB rw-lock implementation
will be instrumented.

FIXME: srv_sys should be removed altogether; it is duplicating tpool
functionality.

fil_crypt_threads_init(): To prevent SAFE_MUTEX warnings, we must
not hold fil_system.mutex.

fil_close_all_files(): To prevent SAFE_MUTEX warnings for
fil_space_destroy_crypt_data(), we must not hold fil_system.mutex
while invoking fil_space_free_low() on a detached tablespace.

LatchDebug::get_level_name(): Implemented as a static function
that references a compile-time constant array of level_names[].
There should be no reason to create a constant std::map of numbers
to compile-time string constants.

We will default to MUTEXTYPE=sys (using OSTrackMutex) for those
ib_mutex_t that have not been replaced yet.

The innodb_fatal_semaphore_wait_threshold will only apply to
InnoDB rw_lock_t, not any mutexes any more.

innodb_sync_debug=ON might still cover ib_mutex_t.

To hopefully avoid increasing contention on lock_sys.mutex,
let us additionally protect trx->lock.wait_lock with trx->mutex
so that lock_wait_suspend_thread() can avoid acquiring
lock_sys.mutex and use trx_t::mutex instead.

Let us replace os_event_t with mysql_cond_t, and replace the
necessary ib_mutex_t with mysql_mutex_t so that they can be
used with condition variables.

The default ib_mutex_t implementation will use os_event_t.

Also, replace polling (os_thread_sleep() or timed waits)
with plain mysql_cond_wait() wherever possible.

FIXME: Add test coverage of
mariabackup --backup --kill-long-queries-timeout

FIXME: innodb_fatal_semaphore_wait_threshold no longer works
because it used to rely on lock_sys.mutex. The test could be
rewritten to rely on an InnoDB rw_lock_t instead.

fts_cache_t::lock: Replaced the rw_lock_t with a mutex.
The only shared latch user was i_s_fts_index_cache_fill(),
for producing content for the view
INFORMATION_SCHEMA.INNODB_FT_INDEX_CACHED.

fts_cache_t::init_lock: Replaced the rw_lock_t with a mutex.
This was only being acquired in exclusive mode.

Let us use a single rw_lock_t::wait_mutex and two condition
variables wait_cond, wait_cond_ex instead of two os_event_t
(which wrap a mutex and condition variable and some other data)

sync_array_wait_event(): Implement new waiting rules for rw_lock_t.
FIXME: Sometimes, rw_lock_s_lock() hangs here. TODO: Find out
what the lock->lock_word is in those cases. Maybe we should
treat not only the value 0 but also X_LOCK_HALF_DECR specially.

This will  avoid some errors on appveyor, due to outdated SDKs.

Though this is an error message task, the problem was deep in the
`mysql_prepare_create_table` implementation. The problem is described as
follows:

1. `append_system_key_parts` was called before
`mysql_prepare_create_table`, though key name generation was done close to
the latest stage of the latter.
2. We can't move `append_system_key_parts` in the end, because system keys
should be appended before some checks done.
3. If the checks from `append_system_key_parts` are moved to the end of
`mysql_prepare_create_table`, then some other inappropriate errors are
issued. like `ER_DUP_FIELDNAME`.

To have key name specified in error message, name generation should be done
before the checks, which consequenced in more changes.

The final design for key initialization in `mysql_prepare_create_table`
follows. The initialization is done in three phases:
1. Calculate a total number of keys created with respect to keys ignored.
 Allocate KEY* buffer.
2. Generate unique names; calculate a total number of key parts.
 Make early checks. Allocate KEY_PART_INFO* buffer.
3. Initialize key parts, make the rest of the checks.

`ha_heap::clone` was creating a handler by share's handlerton, which is
partition handlerton.

handler's handlerton should be used instead.

Here in particular, HEAP handlerton will be used and it will create ha_heap
handler.

The bug was fixed by MDEV-22599 bugfix, which changed `Field::cmp` call
to `Field::cmp_prefix` in `TABLE::check_period_overlaps`.

The trick is that `Field_bit::cmp` apparently calls `Field_bit::cmp_key`,
which condiders an argument an actual pointer to data, which isn't correct
for `Field_bit`, since it stores data by `bit_ptr`. which is in the
beginning of the record, and using `ptr` is incorrect (we use it through
`ptr_in_record` call)

After Sergei's cleanup this assertion is not actual anymore -- we can't
predict if the handler was used for lookup, especially in multi-update
scenario.

`position(old_data)` is made earlier in `ha_check_overlaps`, therefore it
is guaranteed that we compare right refs.

The problem here was that ha_check_overlaps internally uses ha_index_read,
which in case of fail overwrites table->status. Even though the handlers
are different, they share a common table, so the value is anyway spoiled.
This is bad, and table->status is badly designed and overweighted by
functionality, but nothing can be done with it, since the code related to
this logic is ancient and it's impossible to extract it with normal effort.

So let's just save and restore the value in ha_update_row before and after
the checks.

Other operations like INSERT and simple UPDATE are not in risk, since they
don't use this table->status approach.
DELETE does not do any unique checks, so it's also safe.

1. Subtracting table->record[0] from record is UB (non-contiguous buffers)
2. It is very popular to use move_field_offset, which changes Field::ptr,
but leaves table->record[0] unchanged. This makes a ptr_in_record result
incorrect, since it relies on table->record[0] value.
The check ensures the result is within the queried record boundaries.

buf_flush_try_neighbors(): Before invoking buf_page_t::ready_for_flush(),
check that the freshly looked up buf_pool.page_hash entry actually is
a buffer page and not a buf_pool.watch[] sentinel for purge buffering.

This race condition was introduced in MDEV-15053
(commit b1ab211d).
It is rather hard to hit this bug, because
buf_flush_check_neighbors() already checked the condition.
The problem exists if buf_pool.watch_set() was invoked for
a page in the range after the check in buf_flush_check_neighbor()
had been finished.

Thanks to Varun Gupta for suggesting this. This seems to
make main.innodb_ext_key,off more stable.

Invoking memcpy() on a NULL pointer is undefined behaviour
(even if the length is 0) and gives the compiler permission to
assume that the pointer is nonnull. Recent versions of GCC
(starting with version 8) are more aggressively optimizing away
checks for NULL pointers. This undefined behaviour would cause
a SIGSEGV in the test main.func_encrypt on an optimized debug build
on GCC 10.2.0.

This regression was introduced in
commit afc9d00c.
This is a partial backport of
commit 199863d7 from 10.4.

 MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare

The issue here was the system variable max_sort_length was being applied
to decimals and it was truncating the value for decimals to the number
of bytes set by max_sort_length.
This was leading to a buffer overflow as the values were written
to the buffer without truncation and then we moved the offset to
the number of bytes(set by max_sort_length), that are needed for comparison.

The fix is to not apply max_sort_length for fixed size types like INT,
DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and
BLOBS.

Also, revert the work-around for the test that was attempted in
commit 85613a32.

This issue was caught by MemorySanitizer as well as on the
Microsoft Windows debug builds, thanks to /MD being used
starting with 10.4.

The code fix will also be applied to 10.2 because the regression
was introduced in commit afc9d00c.

Test itself is not deterministic.

Disable galera_var_replicate_myisam until fixed on 10.4

Corrects: 7803601d

Use 9 byte (min length packet)

This bug was already fixed in a previous commit.
Added test case from the MDEV to prove it's fixed.

The crash happens because a double free in the case CREATE TABLE fails
because there is a conflicting tables on disk.

Fixed by ensuring that the double free can't happen.

On my system, OpenSuse, I got a compilation error that some arguments
to getgrouplist() where not initialized