Adjust the testcase for MariaDB 10.3+ : prevent IN-to-subquery conversion
optimization from working.

MDEV-23672 (commit 7eda5561)
introduced a regression that can corrupt not only undo log pages,
but anything that resides in the InnoDB buffer pool.

trx_undo_left(): Add debug assertions for the assumptions.
If the pointer is out of bounds, we will return a positive
number, not a negative one. Thus, once a page overflow occurs,
further overflow to adjacent pages will be allowed.
This allows us to remove some more relaxed debug assertions
from some callers.

trx_undo_log_v_idx(): Correctly calculate the size limit.

This bug could manifest itself for a query with WHERE condition containing
top level OR formula such that each conjunct contained a single-range
condition supported by the same index. One of these range conditions must
be fully covered by another range condition that is used later in the OR
formula. Additionally at least one of these condition should be ANDed with
a sargable range condition supported by a different index.

There were several attempts to fix related problems for OR conditions after
the backport of range optimizer code from MySQL (commit
0e19f3e3). Unfortunately the first of these
fixes contained typo remained unnoticed until recently. This typo bug led
to rejection of valid range accesses. This patch fixed this typo bug.
The fix revealed another two bugs: one in a constructor for SEL_ARG,
the other in the function tree_or(). Both are fixed in this patch.

Add a testcase.

Part#1: Revert the patch that caused it:

commit 291be494
Author: Igor Babaev <igor@askmonty.org>
Date:   Thu Sep 24 22:02:00 2020 -0700

    MDEV-23811: With large number of indexes optimizer chooses an inefficient plan

- mysqlnd from PHP < 7.3
- mysql-connector-python any version
- mysql-connector-java any version

Relaxed check about garbage at the end of the packet in case of no parameters.
Added check for array binding.
Fixed test according to the new paradigm (allow junk at the end of the packet)

buf_read_ahead_random(): Do not leak a tablespace reference.
The reference was already acquired in fil_space_t::get(),
and we must only check that operations were not stopped.

This error was introduced when
commit 118e258a
merged n_pending_ios, n_pending_ops into a single n_pending.

This was not noticed earlier, because innodb_random_read_ahead
is OFF by default and our regression tests did not vary that
parameter at all.

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

For some reason, in the test main,innodb_ext_key,off
we frequently get unexpected EXPLAIN output, in particular
on Microsoft Windows debug builders. Let us comment out that
EXPLAIN statement for now.

The problem was that opt_sum_query() was, as part of MIN/MAX optimization,
doing read operations on constant tables that where already closed

Fixed by ensuring we don't try to read from tables that are closed.