This commit fixes sporadic failures in galera_3nodes_sr.GCF-336
test. The following changes have been made here:

1) A small addition to the test itself which should make
   it more deterministic by waiting for non-primary state
   before COMMIT;
2) More careful handling of the wsrep_ready variable in
   the server code (it should always be protected with mutex).

No additional tests are required.

followup for c5896384

dgcov.pl was putting gcov execution counters on wrong lines
in the report (*.dgcov files were correct), because it was
incrementing the new line number for diff lines starting from '-'
(lines from the old file, not present in the new)

* remove dead code
* simplify the check for table->s->next_number_index
* misc

MDEV-29345 update case insensitive (large) unique key with insensitive change of value - duplicate key

use collation-sensitive comparison when comparing fields

password handling as in other command-line tools

followup for 952ab9a5

chery-pick of 814dc467 into 10.5

this fixes galera.galera_sst_mariabackup_table_options

Note that `man snprintf` says

  The functions snprintf() and vsnprintf() do not write more
  than size bytes (including the terminating null byte
  ('\0')). If the output was truncated due to this limit, then
  the return value is the number of characters (excluding the
  terminating null byte) which would have been written to the
  final string if enough space had been available.

dead code for about 10 years

followup for d7df63e1

UDF isn't supposed to use my_error(), it should return
the error message in the provided error message buffer

Fixes valgrind:

==93993== Conditional jump or move depends on uninitialised value(s)
==93993==    at 0x484ECCD: strnlen (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==93993==    by 0x1AD2B2C: process_str_arg (my_vsnprintf.c:259)
==93993==    by 0x1AD47E0: my_vsnprintf_ex (my_vsnprintf.c:696)
==93993==    by 0x1A3B91E: my_error (my_error.c:120)
==93993==    by 0xF87BE8: udf_handler::fix_fields(THD*, Item_func_or_sum*, unsigned int, Item**) (item_func.cc:3638)

followup for 267dd5a9

the test waits for the event to get stuck on MASTER_DELAY,
but on a slow/overloaded slave the event might pass MASTER_DELAY
before the test starts waiting.

Wait for the event to get stuck on the LOCK TABLES (after MASTER_DELAY),
the event cannot avoid that,

and put master-slave.inc *last* in the series of includes

--- func_file_io.result
+++ func_file_io.reject
@@ -134,7 +134,7 @@
 Variable_name	Value
 Performance_schema_accounts_lost	0
 Performance_schema_cond_classes_lost	0
-Performance_schema_cond_instances_lost	0
+Performance_schema_cond_instances_lost	5
 Performance_schema_digest_lost	0
 Performance_schema_file_classes_lost	0
 Performance_schema_file_handles_lost	0

When HA_DUPLICATE_POS is not supported, the row to replace was navigated by
ha_index_read_idx_map, which uses only hash to navigate.

Suchwise, given a hash collision it may choose an incorrect row.

handler::position would be correct and very convenient to use here.

dup_ref is already set by handler independently of the engine
capabilities, when an extra lookup is made (for long unique or something else,
for example WITHOUT OVERLAPS) such error will be indicated by
file->lookup_errkey != -1.

In strict mode a timestamp(0) column could be directly assigned from
another timestamp(N>0) column with the value '1970-01-01 00:00:00.1'
(at time zone '+00:00'), or with any other value '1970-01-01 00:00:00.XXXXXX'
with non-zero microsecond value XXXXXX.
This assignment happened silently without warnings or errors.

It worked as follows:

- The value {tv_sec=0, tv_usec=100000}, which is '1970-01-01 00:00:00.1'
  was rounded to {tv_sec=0, tv_usec=0}, which is '1970-01-01 00:00:00.0'

- Then {tv_sec=0, tv_usec=0} was silently re-interpreted as zero datetime.

After the fix this assignment always raises a warning,
which in case of the strict mode is escalated to an error.

The problem in this scenario is that '1970-01-01 00:00:00' cannot be stored,
because its timeval value {tv_sec=0, tv_usec=0} is reserved for zero datetimes.
Thus the warning should be raised no matter if sql_mode allows or disallows
zero dates.

Field_timestampf::val_native() checked only the
first four bytes to detect zero dates.
That was not enough. Fixing the code to check all packed_length()
bytes to detect zero dates.

The code in Field_timestamp::save_in_field() did not catch
zero datetime and stored it to the other field like a usual value
using store_timestamp_dec(), which knows nothing about zero date and
treats {tv_sec=0, tv_usec=0} as a normal timeval value corresponding to
'1970-01-01 00:00:00 +00:00'.

Fixing the code to catch the special combination (ts==0 && sec_pat==0) and
store it using store_time_dec() with a zero datetime passed as an argument.

When calculating next wakeup timepoint for the timer thread, with large
thread_pool_stall_limit values, 32bit int overflow can happen.
Fixed by making one operand 8 byte large.

Also fixed the type of tick_interval to be unsigned, so it does not
go negative for very thread_pool_stall_limit.

- ZLIB_LIBRARIES, not ZLIB_LIBRARY
- ZLIB_INCLUDE_DIRS, not ZLIB_INCLUDE_DIR

For building libmariadb, ZLIB_LIBRARY/ZLIB_INCLUDE_DIR are still defined
This workaround will be removed later.

This is based on https://github.com/intel/intel-ipsec-mb/
and has been tested both on x86 and x86-64, with code that
was generated by several versions of GCC and clang.
GCC 11 or clang 8 or later should be able to compile this,
and so should recent versions of MSVC.

Thanks to Intel Corporation for providing access to hardware,
for answering my questions regarding the code, and for
providing the coefficients for the CRC-32C computation.

crc32_avx512(): Compute a reverse polynomial CRC-32 using
precomputed tables and carry-less product, for up to 256 bytes
of unaligned input per loop iteration.

Reviewed by: Vladislav Vaintroub

In our unit test, let us rely on our own reference
implementation using the reflected
CRC-32 ISO 3309 and CRC-32C polynomials. Let us also
test with various lengths.

Let us refactor the CRC-32 and CRC-32C implementations
so that no special compilation flags will be needed and
that some function call indirection will be avoided.

pmull_supported: Remove. We will have pointers to two separate
functions crc32c_aarch64_pmull() and crc32c_aarch64().

The two I_S plugins SPIDER_ALLOC_MEM and SPIDER_WRAPPER_PROTOCOL
only makes sense if the main SPIDER plugin is installed. Further,
SPIDER_ALLOC_MEM requires a mutex that requires SPIDER init to fill
the table.

We also update the spider init query to override
--transaction_read_only=on so that it does not affect the spider init.

Also fixed error handling in spider_db_init() so that failure in
spider table init does not result in memory leak

- no need to switch off -fsanitize-address for MSVC anymore
- option /WX is MSVC only
- CMAKE_C_STANDARD C99 is already in pcre's own CMakeLists.txt

The debian/rules removed sufficient version information from the
downstream version, however the mariadb upstream has a +
separator from the suffix.

While we are at it, remove the Debian/Ubuntu revision -1.

Other revisions used:
* Debian unstable (inherited to both Debian and Ubuntu if package unchanged): 1:10.11.6-2
* Ubuntu stable updates example: 1:10.11.6-0ubuntu0.23.10.2
* Debian stable updates example: 1:10.11.4-1~deb12u1

The result is compulation with:
    -DMYSQL_SERVER_SUFFIX="-1:10.4.34+maria~deb10" \

Compared to Debian:
    -DMYSQL_SERVER_SUFFIX="-1~deb12u1" \

The impact comes into play with SELECT VERSION():
    10.4.34-MariaDB-1:10.4.34+maria~deb10

A more abbreviated form of the following is much more human/machine parsable:
    10.6.16-MariaDB~ubu2004

Reviewer: Otto Kekäläinen

Improve detection for DES support in OpenSSL, to allow compilation
against system OpenSSL without DES.

Note that MariaDB needs to be compiled against OpenSSL-like library
that itself has DES support which cmake detected. Positive detection
is indicated with CMake variable HAVE_des 1.
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk>

There is no component `SuportFiles` in MariaDB server, yet a `SupportFiles` component exists.

Analysis:
When we scan json to get to a beginning according to the path, we end up
scanning json even if we have exhausted it. When eventually returns error.

Fix:
Continue scanning json only if we have not exhausted it and return result
accordingly.

Analysis:
When scanning json and getting the exact path at each step, if a path
is reached, we end up adding the item in the result and immediately get the
next item which results in current path changing.
Fix:
Instead of immediately returning the item, count the occurences of the path
in argument and append in the result as needed.

(returns NULL) and for Date/DateTime returns "INTEGER"

Analysis:
When the first character of json is scanned it is number. Based on that
integer is returned.
Fix:
Scan rest of the json before returning the final result to ensure json is
valid in the first place in order to have a valid type.

Backporting add782a1 from 10.6, this fixes the problem.

Regexp_processor_pcre::fix_owner() called Regexp_processor_pcre::compile(),
which could fail on the regex syntax error in the pattern and put
an error into the diagnostics area. However, the callers:
  - Item_func_regex::fix_length_and_dec()
  - Item_func_regexp_instr::fix_length_and_dec()
still returned "false" in such cases, which made the code
crash later inside Diagnostics_area::set_ok_status().

Fix:

- Change the return type of fix_onwer() from "void" to "bool"
  and return "true" whenever an error is put to the DA
  (e.g. on the syntax error in the pattern).
- Fixing fix_length_and_dec() of the mentioned Item_func_xxx
  classes to return "true" if fix_onwer() returned "true".

We have to #undef my_error and find it from udfs when spider is not
installed.