MDEV-24965 With ALTER USER ...IDENTIFIED BY command, password doesn't replaced by asterisks in audit log.

Test result fixed.

MDEV-24965 With ALTER USER ...IDENTIFIED BY command, password doesn't replaced by asterisks in audit log.

Check for the ALTER USER command added.

The reason for the crash was that there was not a write lock to
protect against file rotations in the server_audit plugin after an
audit plugin patch to changed audit mutexes to read & write locks.

The fixes are:
* Moving server_audit.c to use read & write locks (which improves
  performance).
* Added functionality in file_logger.c to not do file rotations until
  it is allowed by the caller (done without any interface changes for
  the logging service).
* Move checking of file size limit to server_audit.c and if it is time to
  do a rotation change the read lock to a write lock and tell file_logger
  that it is now allowed to rotate the log files.

Correcting an incorrect merge from 10.2

Backport of 4bc31a90

Include client libraries for auth caching_sha2_password and
sha256_password in the libmariadb3 client library package.

volatile != atomic.

volatile has no memory barrier schemantics, its for mmaped IO
so lets allow some optimizer gains and stop pretending it helps
with memory atomicity.

The MDEV lists a SEGV an assumption is made that an address was
partially read. As C packs structs strictly in order and on arm64 the
cache line size is 128 bits. A pointer (link - 64 bits), followed
by a hashnr (uint32 - 32 bits), leaves the following key (uchar *
64 bits), neither naturally aligned to any pointer and worse, split
across a cache line which is the processors view of an atomic
reservation of memory.

lf_dynarray_lvalue is assumed to return a 64 bit aligned address.

As a solution move the 32bit hashnr to the end so we don't get the
*key pointer split across two cache lines.

Tested by: Krunal Bauskar
Reviewer: Marko Mäkelä

This bug caused crashes of the server when processing queries with table
value constructors (TVC) that contained subqueries and were used itself as
subselects. For such TVCs the following transformation is applied at the
prepare stage:
  VALUES (v1), ... (vn) => SELECT * FROM (VALUES (v1), ... (vn)) tvc_x.
This transformation allows to reduce the problem of evaluation of TVCs used
as subselects to the problem of evaluation of regular subselects.
The transformation is implemented in the wrap_tvc(). The code the function
to mimic the behaviour of the parser when processing the result of the
transformation. However this imitation was not free of some flaws. First
the function called the method exclude() that completely destroyed the
select tree structures below the transformed TVC. Second the function
used the procedure mysql_new_select to create st_select_lex nodes for
both wrapping select of the transformation and TVC. This also led to
constructing of invalid select tree structures.
The patch actually re-engineers the code of wrap_tvc().

Approved by Oleksandr Byelkin <sanja@mariadb.com>

Introduced by 85828b8f

This is running 2 git processes in parallel, which, if unlucky can cause
either of them to fail with "File already exists" error.

- The commit 5fd3c747(MDEV-24709)
resets the recv_no_ibuf_operations in
recv_recovery_from_checkpoint_start(), but InnoDB fails to reset
the variable recv_no_log_write() during that time and that leads
to the assert failure.

This was caused by two different bugs:
1) Information_schema tables where not locked by lock_tables, but
   get_lock_data() was not filtering these out. This caused a crash when
   mysql_unlock_some_tables() tried to unlock tables early, including
   not locked information schema tables.

Fixed by not locking SYSTEM_TMP_TABLES

2) In some cases the optimizer will notice that we do not need to read
   the information_schema tables at all. In this case
   join_tab->read_record is not set, which caused a crash in
   get_schema_tables_result()

Fixed by ignoring const tables in get_schema_tables_result()

1. wait for the binlog thread to reach the certain state, don't use
   a debug_sync that's incorrectly placed to detect the state
2. no need to do a (non-deterministic) `show binlog events` to verify
   what is guaranteed by the directly preceding line

if it's the whole content of a test anyway.

add a new "debugger" to mtr, that runs the executable
under valgrind in gdb. valgrind pid is auto-detected,
but the delay (sleep) and vgdb path are hard-coded for now

"debugger" is anything that wraps execution of a target
binary (mysqld or mysqltest). Currently the list includes:
gdb, ddd, dbx, lldb, valgrind, strace, ktrace, rr,
devenv, windbg, vsjitdebugger.

for every debugger xxx, mtr will recognize four options:
--xxx, --boot-xxx, --manual-xxx, --client-xxx.
They all support an optional "=string" argument. String
being a semicolon-separated list of commands (e.g. for gdb)
or one (not semicolon-separated) command line of options
(e.g. for valgrind). Or both (e.g. --gdb='-quiet -nh;info files'

In embedded both --xxx and --client-xxx work.

Functionality changed/removed:
* --rr-args is gone
* --rr-dir is gone
* --manual-debug is gone
* --debugger={devenv|vc|windbg|vc_express|vsjitdebugger} is gone
* --strace-option is gone
* --stracer={strace|ktrace} is gone
* --valgrind only enables it for the server, not for everything
* --valgrind-all is gone
* --valgrind-mysqltest is gone
* --valgrind-mysqld is gone
* --valgrind-options is gone
* --valgrind-option is gone
* --valgrind-path is gone
* --callgrind is gone
* one cannot combine --valgrind --gdb anymore
* valgrind report doesn't add a fake test line to the output
* vc and vcexpress on windows are no longer supported

don't allocate Column_statistics_collected objects that won't
be used.

minor style fixes (StringBuffer<>, etc)

only collect persistent stats for columns explicitly listed
by the user in the  ANALYZE TABLE PERSISTENT FOR COLUMNS (...)
clause. The engine can extend table->read_set as much as
it wants, it should not affect the collected statistics.

Test case from the 3b94309a applies - it used to crash,
because ha_partition extended table->read_set after the loop that
initialized some objects based on bits in the read_set but before the
loop that used these objects based on bits in the read_set.

This reverts the commit 3b94309a but keeps the test

Because the fix is a hack that isn't supposed to do anything,
and relies on a side-effect of rnd_init inside ha_partition.

A different fix is coming up.

           on used subqueries

If a query was based on a table value constructor that contained subqueries
then EXPLAIN for such query did not contain any lines explaining the
execution plans of the subqueries.
This happened because
- no optimize() method was called for any subquery used by the table value
  constructor when EXPLAIN command for the query was processed;
- EXPLAIN node created for the table value constructor itself did not
  assume that some child nodes could be attached to it.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

- This is caused by commit ad6171b9
(MDEV-22456). InnoDB reloads the evicted table again from dictionary.
In that case, AHI entries and current index object mismatches
happens. When index object mismatches then InnoDB should drop
the page hash AHI entries for the block. In
btr_search_drop_page_hash_index(), InnoDB should take exclusive
lock on the AHI latch if index is already freed to avoid the
freed memory access during buf_pool_resize()

This can cause crashes when accessing already released memory

The issue was the Item_default created a internal field, pointing to
share->default_values, to be used with the DEFAULT() function.
This does not work for BLOB fields as these are freed at end of query.
Fixed by storing BLOB field data inside and area allocated by
Item_default_value,  like we do for nondeterministic default values.

this should simplify run-time cluster management

MDEV-24873 : galera.galera_as_slave_ctas MTR failed: Assertion `(&(&LOCK_thd_data)->m_mutex)->count > 0 && pthread_equal(pthread_self(), (&(&LOCK_thd_data)->m_mutex)->thread)' failed in sql_class.cc on THD::awake(killed_state)

Problem was that thd::awake assumes now that you hold THD::LOCK_thd_data
so we need to keep it when we call wsrep_thd_awake from
wsrep_abort_transaction.

Problem was that we tried to lock THD::LOCK_thd_data after we have
acquired lock_sys mutex. This is against mutex ordering rules.

Stabilize test case.

Let us avoid the excessive allocation of explicit record locks
(a work-around of MDEV-24813) so that the test will execute
much faster under AddressSanitizer, MemorySanitizer, Valgrind.