.. a later spotted need to address parallel XAP_1 and T_2 in
which T_2 does not find XAP_1 as prepared and still it should skip
its locks.

- non-unique index related examination evacuates thd_rpl_deadlock_check
  into a new thd_rpl_xa_non_uniq_index_hit
- thd_rpl_xa_non_uniq_index_hit also covers a case of an ongoing
  XA-Prepare parent (whose locks are allowed to be skipped at
  scanning)
- preparation for a simulated delay for next commit tests.

An earlier added
  rpl_group_info::exec_flags
  remains. The reasons are that its alternative of a new HA_ error
  would be slave specific while, as pointed in review mail thread -
  the added bit flag may provide more service in future).

This work partly implements a ROW binlog format MDEV-33455 part
that is makes non-unique-index-only table XA replication safe in RBR.
Existence of at least one non-null unique index has always guaranteed
safety (no hang to error).

Two transaction that update a non-unique-only index table could not be
isolated on slave when on slave they used different non-unique indexes
than on master.
Unsolvable hang could be seen in case the first of the two is a prepared XA

--connection slave_worker_1

  xa start 'xid'; /* ... lock here ... */ ; xa prepare 'xid'

while the 2nd being of any kind including of normal type

--connection slave_worker_2

  begin; /* ... get lock ... => wait/hang...error out  */

was unable to wait up for the conflicting lock, even though
the XA transaction did not really lock target records of the 2nd.

This type of hang was caused by a chosen method the 2nd transaction
employs to reach the target record, which is the index scan. The scanning
orthodoxically just could not step over a record in the way that was
locked by the XA.
However as the in-the-way record can not be targeted by the 2nd
transaction, otherwise the transactions would have sensed the conflict
back on master *and* the other possibility of collecting extra locks by the
'xid' on non-modified records is tacked by MDEV-33454/MDEV-34466,
the non-unique index scanning server/slave-applier layer must not panic at
seeing a timeout error from the engine. Instead the scanning would
just proceed to next possibly free index records of the same key value and
ultimately must reach the target one.
More generally, on the way to its target all busy records belonging to
earlier (binlog order) prepared XA transactions need not be tried locking
by the current non-unique index scanning transaction.

This patch implements the plan for Innodb.
The server layer expects the engine to mark an attempt to wait for
a conflicting lock that belongs to a transaction in prepared state.
The engine won't exercise, need not to, the timeout wait.
When marking is done the timeout error is ignored by the server
and next index record is tried out.

An mtr test checks a scenario in sequential and parallel modes.

Regression tests.

lock_rec_unlock_unmodified() is executed either under lock_sys.wr_lock()
or under a combination of lock_sys.rd_lock() + record locks hash table
cell latch. It also requests page latch to check if locked records were
changed by the current transaction or not.

Usually InnoDB requests page latch to find the certain record on the
page, and then requests lock_sys and/or record lock hash cell latch to
request record lock. lock_rec_unlock_unmodified() requests the latches
in the opposite order, what causes deadlocks. One of the possible
scenario for the deadlock is the following:

thread 1 - lock_rec_unlock_unmodified() is invoked under locks hash table
           cell latch, the latch is acquired;
thread 2 - purge thread acquires page latch and tries to remove
           delete-marked record, it invokes lock_update_delete(), which
           requests locks hash table cell latch, held by thread 1;
thread 1 - requests page latch, held by thread 2.

To fix it we need to release lock_sys.latch and/or lock hash cell latch,
acquire page latch and re-acquire lock_sys related latches.

THIS COMMIT DOES NOT PASS RQG TESTING, DON'T PUSH IT WITHOUT FIXING.

There is no need to exclude exclusive non-gap locks from the procedure
of locks releasing on XA PREPARE execution in
lock_release_on_prepare_try() after commit
17e59ed3 (MDEV-33454), because
lock_rec_unlock_unmodified() should check if the record was modified
with the XA, and release the lock if it was not.

lock_release_on_prepare_try(): don't skip X-locks, let
lock_rec_unlock_unmodified() to process them.

lock_sec_rec_some_has_impl(): add template parameter for not acquiring
trx_t::mutex for the case if a caller already holds the mutex, don't
crash if lock's bitmap is clean.

row_vers_impl_x_locked(), row_vers_impl_x_locked_low(): add new argument
to skip trx_t::mutex acquiring.

rw_trx_hash_t::validate_element(): don't acquire trx_t::mutex if the
current thread already holds it.

Thanks to Andrei Elkin for finding the bug.
Reviewed by Marko Mäkelä, Debarun Banerjee.

The lsof utility is prone to blocking on system calls that
it uses to obtain information about sockets (or files, devices,
etc.). This behavior is described in its own documentation.
It has a '-b' option (in combination with warnings suppression
via '-w') that reduces the probability of blocking, introducing
new problems (luckily probably not relevant for our use case).
However, there is no guarantee that it will not hang on some
distributions, with some TCP/IP stack implementations, or with
some filesystems, etc. Also, of the three utilities that are
suitable for our purposes, lsof is the slowest. So if there
are other utilities that we use during SST, such as 'ss' or
'sockstat', it is reasonable to use them instead of lsof.
This commit changes the prioritization of utilities, it does
not need additional tests (besides the numerous SST tests
already available in the galera suites). If the system still
need to use lsof, this commit adds the '-b' and '-w' options
to it command line - to reduce the likelihood of blocking.

Removed handling of the long-unsupported xtrabackup_pid file,
as it is not even created by modern versions of mariabackup.
Instead, added stopping of the asynchronous process that
mariabackup runs (if it is still active) to the exception
handler.

This commit makes the SST script for mariabackup more
resilient to unexpected terminations or hangs while
mariabackup or when SST scripts in a previous session
are still running (in reality they were hung while
waiting for something).

GCC 12.2.0 could issue -Wnonnull for an unreachable call to
strlen(new_path).  Let us prevent that by replacing the condition
(type == FILE_RENAME) with the equivalent (new_path).
This should also optimize the generated code, because the life time
of the parameter "type" will be reduced.

my_b_encr_write(): Initialize also block_length, and at the same time
last_block_length, so that all 128 bits can be initialized with fewer
writes. This fixes an error that was caught in the test
encryption.tempfiles_encrypted.

test_my_safe_print_str(): Skip a test that would attempt to
display uninitialized data in the test unit.stacktrace.
Previously, our CI did not build unit tests with MemorySanitizer.

handle_delayed_insert(): Remove a redundant call to pthread_exit(0),
which would for some reason cause MemorySanitizer in clang-19 to
report a stack overflow in a RelWithDebInfo build. This fixes a
failure of several tests.

Reviewed by: Vladislav Vaintroub

Emit a warning in the event that we finished processing input files
before reaching the boundary indicated by --stop-datetime.

Emit a warning in the event that we finished processing input files
before reaching the boundary indicated by --stop-position.

buf_page_t::read_complete(): Fix an incorrect condition that had been
added in commit aaef2e1d (MDEV-27058).
Also for compressed-only pages we must remember that buffered changes
may exist.

buf_read_page(): Correct the function comment; this is for a synchronous
and not asynchronous read. Pass the parameter unzip=true to
buf_read_page_low(), because each of our callers will be interested in
the uncompressed page frame. This will cause the test
encryption.innodb-compressed-blob to emit more errors when the
correct keys for decrypting the clustered index root page are unavailable.

Reviewed by: Debarun Banerjee

buf_pool_t::page_fix(): If a change buffer merge may be needed on a
ROW_FORMAT=COMPRESSED page that exists in compressed-only format in
the buffer pool, go ahead to decompress the block. This fixes an
infinite loop.

Reviewed by: Debarun Banerjee

Add support for removing the Content-Type header to the S3 engine. This
is required for compatibility with some S3 providers.

This also adds a provider option to the S3 engine which will turn on
relevant compatibility options for specific providers.

This was required for getting MariaDB S3 engine to work with "Huawei
Cloud S3".
To get Huawei S3 storage to work on has set one of the following
S3 options:
s3_provider=Huawei
s3_ssl_no_verify=1

Author: Andrew Hutchings <andrew@mariadb.org>

The 10.5->10.6 merge commit 3bc98a4e casts the arg to an int16
pointer in set_extraction_flag_processor(). This matched the previous
commit c76eabfb where set_extraction_flag was changed to have int16 arg
instead of int.

The commit a5e4c349 for MDEV-29363 added a call to
set_extraction_flag_processor on IMMUTABLE_FL (MARKER_IMMUTABLE in 10.6).
The subsequent 10.5->10.6 merge f071b762 did not cast the flag
to int16 when merging this change.

The result is big-endian processors cleared the immutable
flag rather than set the flag, resulting in MDEV-29363
being unfixed on big-endian processors.

MDEV-31788 Factor functions to reduce duplication around spider_check_and_init_casual_read in ha_spider.cc

factored out static functions:
- spider_prep_loop
- spider_start_bg
- spider_send_queries

They are for unnecessary debugging purposes only.

The functions called in blocks protected by this macro remain
undefined as of 11.5 c96b23f9

It's virtually empty now