btr_cur_upd_rec_in_place(): Prefer WRITE to MEMSET for a single-byte
operation.

log_phys_t::apply(): Relax the assertion to allow a single-byte MEMSET,
even though it is 1 byte longer than a WRITE record.

Test code modifications and new failures from buildbot were registered
only for the main suite. The rest was updated partially,
based on the status of existing JIRA items

reset thd->lex->query_tables_own_last,
because open_table() uses it and will try to dereference
whatever garbage it might have

The reason for this is that Galera can lock LOCK_thd_data for a long time.

Instead of stalling any long running process, like alter or repair table,
because of progress reporting, ignore the progress reporting for this
call. Progress reporting will continue on the next call after the lock has
been released.

The fix of MDEV-24569 and MDEV-24695 introduced a race condition when
a table is being rebuilt or dropped during the fseg_page_is_free() check.
The server would occasionally crash during the execution of the test
encryption.create_or_replace.

The fil_space_t::STOPPING flag can be set by DDL operations. Normally,
such concurrent operations are prevented by a metadata lock (MDL).
However, neither the change buffer merge nor the fil_crypt_thread() are
protected by MDL.

fil_crypt_read_crypt_data(), xdes_get_descriptor_const(): Pass the
BUF_GET_POSSIBLY_FREED flag to avoid the fatal error in buf_page_get_low()
if a DDL operation was just initiated.

Related to commit f0baa864 and MDEV-23632.

When creating a summary temporary table with bit fields used in the sum
expression with several parameters, like GROUP_CONCAT(), the counting of
bits needed in the record was wrong.

The reason we got an assert in Aria was because the bug caused a memory
overwrite in the record and Aria noticed that the data was 'impossible.

wsrep_cluster_address_update() causes LOCK_wsrep_slave_threads
to be locked under LOCK_wsrep_cluster_config, while normally
the order should be the opposite.

Fix: don't protect @@wsrep_cluster_address value with the
LOCK_wsrep_cluster_config, LOCK_global_system_variables is enough.

Only protect wsrep reinitialization with the LOCK_wsrep_cluster_config.
And make it use a local copy of the global @@wsrep_cluster_address.

Also, introduce a helper function that checks whether
wsrep_cluster_address is set and also asserts that it can be safely
read by the caller.

Problem was that when engine substitution is allowd (e.g. sql_mode='')
we must also check db_type. Additionally, we did not resolve
default storage engine on that case and used that to check is
TOI possible or not.

rarely (try --repeat 1000), the following happens:

* from wsrep_bf_abort (when a thread is being killed), wsrep-lib
starts streaming_rollback that wants to
convert_streaming_client_to_applier. wsrep_create_streaming_applier
creates a new THD(). All while the other THD is being killed,
so under LOCK_thd_kill and LOCK_thd_data. In particular, THD::init()
takes LOCK_global_system_variables under LOCK_thd_kill.

* updating @@wsrep_slave_threads takes LOCK_global_system_variables
and LOCK_wsrep_cluster_config (in that order) and invokes
wsrep_slave_threads_update() that takes LOCK_wsrep_slave_threads

* wsrep_replication_process() takes LOCK_wsrep_slave_threads and
invokes wsrep_close_applier(), that does thd->set_killed() which
takes LOCK_thd_kill.

et voilà.

As a fix I copied a workaround from wsrep_cluster_address_update()
to wsrep_slave_threads_update(). It seems to be safe: without mutexes
a race condition is possible and a concurrent SET might change
wsrep_slave_threads, but wsrep_slave_threads_update() always verifies
if there's a need to do something, so it will not run twice in this case,
it'll be a no-op.

let the caller take the lock if needed

adaptation of 29bbcac0 for 10.4

* reuse the loop in THD::abort_current_cond_wait, don't duplicate it
* find_thread_by_id should return whatever it has found, it's the
  caller's task not to kill COM_DAEMON (if the caller's a killer)

and other minor changes

Test code modifications and new failures from buildbot registered
only for the main suite. The rest was updated partially,
based on the status of existing JIRA items

Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution"
was null-merged. 10.4 version of the fix is coming up separately

The Readline library is no longer available in Debian Sid.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980504

Add the dependency on-the-fly in autobake-deb.sh for older distro versions
and keep the native build in a state that works on Debian Sid as-is.

The older MariaDB.org packages were built against libreadline5 and depend
on it to install. As it was removed from Sid (and Bullseye), fetch and
install it from Buster.

This can eventually be removed once we stop backwards compat testing for
older MariaDB versions (new ones don't depend on it).

Upstreamed from Debian packaging repository commit
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/commit/4b729db7f89f573dbe92d601a2d984fab158fc4f

and S3_HOST_NAME.

Required environment variables are now S3_ACCESS_KEY and S3_SECRET_KEY.

Or a running minio instance on localhost:9000.

Was added in 10.5.2 (MDEV-21975)

A few of the failures was because of missing sync_slave_to_master in
the test suite.

However, the biggest reason for most faulures was that in case of
ALTER PARTITION the master writes the query to the binary log before
it has updated the .frm and .par files. This causes a problem for an
S3 slave as it will start execute the ALTER PARTITION but get old .frm and
.par files from S3 which causes "open table" to fail, either with an error
or in some case with a crash.
Fixed

This allow one to remove some casts like:
maria_data_root= (char *)".";

It also removes warnings from icc.

One should not change the program arguments!
This change also reduces warnings from the icc compiler.

Almost all changes are just syntax changes (adding const to
'get_one_option function' declarations).

Other changes:
- Added a few cast of 'argument' from 'const char*' to 'char *'. This
  was mainly in calls to 'external' functions we don't have control of.
- Ensure that all reset of 'password command line argument' are similar.
  (In almost all cases it was just adding a comment and a cast)
- In mysqlbinlog.cc and mysqld.cc there was a few cases that changed
  the command line argument. These places where changed to instead allocate
  the option in a MEM_ROOT to avoid changing the argument. Some of this
  code was changed to ensure that different programs did parsing the
  same way. Added a test case for the changes in mysqlbinlog.cc
- Changed a few variables that took their value from command line options
  from 'char *' to 'const char *'.

partially revert 76063c2a. Item::clone() is not an all-purpose
Item copying machine, it was specifically created for pushdown
of predicates into derived tables and views and it does not
copy everything. In particular, it does not copy Item_func_regex.

Fix the bug differently by preserving the old constraint name.
But keep setting automatic_name=true to have it regenerated
for cases like ALTER TABLE ... ADD CONSTRAINT.

The condition variables that were introduced in
commit 7cffb5f6 (MDEV-23399)
are never instrumented with PERFORMANCE_SCHEMA.
Let us avoid the storage overhead and dead code.

Test code modifications and new failures from buildbot registered
only for the main suite. The rest was updated partially,
based on the status of existing JIRA items

Use size_t everywhere and remove suspicious expression.

The test case was setting aria_sort_buffer_size to MAX_ULONGLONG-1
which was not handled gracefully by my_malloc() or safemalloc().
Fixed by ensuring that the malloc functions returns 0 if the size
is too big.
I also added some protection to Aria repair:
- Limit sort_buffer_size to 16G (after that a bigger sort buffer will
  not help that much anyway)
- Limit sort_buffer_size also according to sort file size. This will
  help by not allocating less memory if someone sets the buffer size too
  high.

win