The Shared/Update/Exclusive locks that were introduced in
commit 03ca6495 (MDEV-24142)
did not work correctly when a futex-like system call interface
was not available.

On all tested implementations (IBM AIX as well as FreeBSD and GNU/Linux
with the futex interface artificially disabled), the old implementation
would cause hangs in some SPATIAL INDEX tests (innodb_gis suite).
On FreeBSD, a hang was also observed in an encryption test.

We will simply emulate the futex system calls with a single mutex
and two condition variables, one for each wait queue. The condition
variables basically shadow the lock words and are used as wait queues,
just like the futex system calls would be.

The storage overhead of ssux_lock_impl will be increased by 32 bits
when using SUX_LOCK_GENERIC. Compared to the futex-based implementation,
the SUX_LOCK_GENERIC implementation has an overhead of
sizeof(pthread_mutex_t)+2*sizeof(pthread_cond_t).

rw_lock: Remove all SUX_LOCK_GENERIC extensions.

pthread_mutex_wrapper: A simple wrapper of pthread_mutex that
implements srw_spin_mutex and srw_mutex for SUX_LOCK_GENERIC.

srw_mutex_impl: Define this also for SUX_LOCK_GENERIC, but in
that case add the fields mutex, cond.

ssux_lock_impl: Define for SUX_LOCK_GENERIC with a minimal difference:
adding readers_cond.

kill_one_thread(): Fix integer sign mismatch in some format strings.
Some of this was introduced
in commit 5c230b21

Cherry-pick the sql_kill and sql_user_kill from ef2dbb8d

Changed ER_CANNOT_USER to ER_KILL_DENIED_ERROR to match
other kill denied user messages.

Cherry-pick by Daniel Black.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

As as discussed with @dbart we decided to move
https://deb.mariadb.org/repo to https://deb.mariadb.org so that a
request on https://deb.mariadb.org will end up directly in
https://mirror.mariadb.org/repo.

The same behavior was configured for rpms (https://rpm.mariadb.org -->
https://mirror.mariadb.org/yum) this also makes the old yum.mariadb.org
service transparently compatible with this new service (after DNS change
to point to rpm.mariadb.org).

See also: https://jira.mariadb.org/browse/MDBF-297

We will remove the parameter innodb_disallow_writes because it is badly
designed and implemented. The parameter was never allowed at startup.
It was only internally used by Galera snapshot transfer.
If a user executed
SET GLOBAL innodb_disallow_writes=ON;
the server could hang even on subsequent read operations.

During Galera snapshot transfer, we will block writes
to implement an rsync friendly snapshot, as follows:

sst_flush_tables() will acquire a global lock by executing
FLUSH TABLES WITH READ LOCK, which will block any writes
at the high level.

sst_disable_innodb_writes(), invoked via ha_disable_internal_writes(true),
will suspend or disable InnoDB background tasks or threads that could
initiate writes. As part of this, log_make_checkpoint() will be invoked
to ensure that anything in the InnoDB buf_pool.flush_list will be written
to the data files. This has the nice side effect that the Galera joiner
will avoid crash recovery.

The changes to sql/wsrep.cc and to the tests are based on a prototype
that was developed by Jan Lindström.

Reviewed by: Jan Lindström

Closes #2084

Closes #2083

Closes #2082

Add compression plugins:
  * bzip2
  * lz4
  * lzma
  * lzo
  * snappy
To Autopkg's basic smoke-test dependencies.

Also make sure that MariaDB service is reloaded
when smoke-test is executed.

Some SQL statements that involves subqueries or stored routines could
fail since execution of subqueries or stored routines is not supported
for theses statements. Unfortunately, parsing error could result in
abnormal termination by firing the following assert
  DBUG_ASSERT(m_thd == NULL);
in a destructor of the class sp_head.

The reason of the assert firing is that the method
  sp_head::restore_thd_mem_root()
is not called on semantic action code to clean up resources allocated
during parsing. This happens since the macros YYABORT is called instead of
MYSQL_YYABORT by semantic action code for some grammar rules.

So, to fix the bug YYABORT was just replaced with MYSQL_YYABORT.

after moving fields in optimize_schema_tables_memory_usage()
store default values into their new, moved, locations.

This reverts commit 0812d0de.
But keeps the test case.

followup for 58cd2a8d

As MariaDB 10.5 has been removed from Debian Sid and MariaDB 10.6 has
entered it, the Salsa-CI testing needs to adapt.

To achieve this, essentially sync most the the salsa-ci.yml contents from
https://salsa.debian.org/mariadb-team/mariadb-server/-/tree/debian/latest

This includes removing Stretch builds, as Stretch does not support uring
nor pmem libraries, which MariaDB 10.6 depends on.

Also add a couple Lintian overrides to make Salsa-CI pass.

NOTE TO MERGERS: This commit is made on 10.6 branch and can be merged to
all later branches (10.7, 10.8, 10.9..) for now, but later somebody needs
to go in and update all the testing stages to do the upgrade testing
correctly for 10.6->10.7->10.8->10.9 etc.

- InnoDB bulk insert operation fails to rollback when it detect
DB_DUPLICATE_KEY error. It leads to orphaned records in primary
indexes. Consecutive update/delete operation assumes that record
should exist in secondary index and it leads to failure.

- After MDEV-24621, InnoDB does buffer the insert bulk operation
for all indexes expect spatial one. But it leads to search the
primary key lookup and it leads to failure. So InnoDB should avoid
bulk insert when table has spatial index involved.

The reason for this fix was that when I tried to run mysql_upgrade
at home to update an old 10.5 installation, mysql_upgrade failed
with warnings about mariadb.sys user not existing.

If the server was started with --skip-grants, there would be no warnings
from mysql_upgrade, but in some cases running mysql_upgrade again could
produce new warnings.

The reason for the warnings was that any access of the mysql.user view
will produce a warning if the mariadb.sys user does not exists.

Fixed with the following changes:
- Disable warnings about mariadb.sys user not existing
- Don't overwrite old mariadb.sys entries in tables_priv and global_priv
- Ensure that tables_priv has an entry for mariadb.sys if the user exists.
  This fixes an issue that tables_priv would not be updated if there
  was a failure directly after global_priv was updated.

Server crashed during shutdown with:
"corrupted double-linked list"
when running mysql_upgrade multiple times against the server.

Reason was that db_repostitory could be freed twice.

This commit contains a fix to use modern syntax for selecting
character classes in the tr utility options.

Also one of the tests for SST via rsync (galera_sst_rysnc2) is made
more reliable (to avoid rare failures during automatic testing).

The issue is caused by 59a0236d commit.
The initial intention of the commit was to speed up
"mariabackup --prepare".

The call stack of binlog position reading is the following:
▾ trx_rseg_mem_restore
  ▾ trx_rseg_array_init
      ▾ trx_lists_init_at_db_start
            ▸ srv_start
Both trx_lists_init_at_db_start() and trx_rseg_mem_restore() contain
special cases for srv_operation == SRV_OPERATION_RESTORE condition, and
on this condition only rseg headers are read to parse binlog position.
Performance impact is not so big.

The solution is to revert 59a0236d.

ib_id_t is a uint64. On AIX this isn't a long long unsigned and to
prevent the compile warnings and potential wrong type, the UINT64PFx
defination is corrected.

As INT64PF is unused (last use, xtradb in 10.2), it is removed to
remove the confusion that INT64PF and UINT64PFx would be different
types otherwise.

This bug report is not about ASAN Use After Free issue. This bug is
about missed calling of the method LEX::cleanup_lex_after_parse_error
that should happen on parse error.

Aforementioned method calls sphead::restore_thd_mem_root to clean up
resources acquired on processing a stored routine. Particularly,
the method sp_head::restore_tht_mem_root is called to restore
an original mem root and reset LEX::sphead into nullptr.

The method LEX::cleanup_lex_after_parse_error is invoked by the macros
MYSQL_YYABORT. Unfortunately, some rules of grammar for handling
user variables in SQL use YYABORT instead of MYSQL_YYABORT to handle
parser errors. As a consequence, in case a statement with setting of
a user variable is called inside a stored routine, it results in
assert failure in sp_head destructor.

To fix the issue the macros YYABORT should be replaced by MYSQL_YYABORT
in those grammar rules that handle assignment of user variables.

The "const" qualifier was obviously forgotten.

This change will also simpily fixing of MDEV-27744.

Fixing a typo in the fix for MDEV-19804, wrong return value in a bool function:
 < return NULL;
 > return true;

The problem was found because it did not compile on some platforms.

Strangley, it did not have visible problems on other platforms,
which did not fail to compile, although "return NULL" should compile to
"return false" rather than "return true".

tv_usec is a (suseconds_t) so we cast to it. Prevents the AIX(gcc-10) warning:

include/my_time.h: In function 'void my_timeval_trunc(timeval*, uint)':
include/my_time.h:249:65: warning: conversion from 'long int' to 'suseconds_t' {aka 'int'} may change value [-Wconversion]
  249 |   tv->tv_usec-= my_time_fraction_remainder(tv->tv_usec, decimals);
      |

macOS is: conversion from 'long int' to '__darwin_suseconds_t' {aka 'int'} may change value

On Windows suseconds_t isn't defined so we use the existing
long return type of my_time_fraction_remainder.

Reviewed by Marko Mäkelä

Closes: #2079