after d7d3ad69 debug_sync waits are no longer interrupted by
soft kills that server shutdown is using. Luckily in this test
there's no need to wait, it wants the commit to be properly completed,
fully committed in both engines.

We do not need a non-inline wrapper for the function
destroy_background_thd().

thd_get_ha_data() can be used without a lock, but only from the
current thd thread, when calling from anoher thread it *must*
be protected by thd->LOCK_thd_data

* fix group commit code to take thd->LOCK_thd_data
* remove innobase_close_connection() from the innodb background thread,
  it's not needed after 87775402 and was failing the assert with
  current_thd==0

MDEV-29368 Assertion `trx->mysql_thd == thd' failed in innobase_kill_query from process_timers/timer_handler and use-after-poison in innobase_kill_query

This is a 10.5 version of 9b750dcb, fix for
MDEV-23536 Race condition between KILL and transaction commit

InnoDB needs to remove trx from thd before destroying it (trx), otherwise
a concurrent KILL might get a pointer from thd to a destroyed trx.

ha_close_connection() should allow engines to clear ha_data in
hton->on close_connection(). To prevent the engine from being unloaded
while hton->close_connection() is running, we remove the lock from
ha_data and unlock the plugin manually.

split it into debug and non-debug tests

only "hard" kills will now interrupt debug_sync waits.
this is needed to have debug_sync points that work during disconnect

rather than mariadb/mariadb-check

This reverts commit bdc5548c
that introduced a work-around to ha_innobase::delete_table()
for avoiding failures when trying to remove table partitions.

This work-around (of not removing statistics in case of a locking
conflict) would occasionally cause a failure of the test
parts.part_supported_sql_func_innodb:

mysqltest: In included file "./suite/parts/inc/partition_supported_sql_funcs.inc":
included from ./suite/parts/inc/part_supported_sql_funcs_main.inc at line 91:
included from /buildbot/amd64-ubuntu-2004-msan/build/mysql-test/suite/parts/t/part_supported_sql_func_innodb.test at line 44:
At line 234: query 'alter table t66
reorganize partition s1 into
(partition p0 values less than ($valsqlfunc),
partition p1 values less than maxvalue)' failed: ER_DUP_KEY (1022): Can't write; duplicate key in table 'mysql.innodb_table_stats'

ha_innobase::delete_table(): If locking the InnoDB persistent statistics
tables mysql.innodb_table_stats or mysql.innodb_index_stats fails for
a table partition, proceed to drop the partition. On DROP TABLE of a
partitioned table, each partition is being dropped in a separate
InnoDB DDL transaction. The only practical way to create an illusion of
atomicity is to avoid failures.

krb5-config (used by FindGSSAPI) returns `-lkrb5 -lk5crypto -lcom_err`
but only libkrb5 is actually used by the gssapi plugin. The other two
result in unneeded dependencies unless they're tagged optional when
linked with --as-needed.

Some distributions use --as-needed automatically, which causes our
builds to differ from srpm builds, introducing failures in buildbot.

Let's always use --as-needed for gssapi plugin

There are separate flags DBUG_OFF for disabling the DBUG facility
and ENABLED_DEBUG_SYNC for enabling the DEBUG_SYNC facility.
Let us allow debug builds without DEBUG_SYNC.

Note: For CMAKE_BUILD_TYPE=Debug, CMakeLists.txt will continue to
define ENABLED_DEBUG_SYNC.

In commit 28325b08
a compile-time option was introduced to disable the macros
DBUG_ENTER and DBUG_RETURN or DBUG_VOID_RETURN.

The parameter name WITH_DBUG_TRACE would hint that it also
covers DBUG_PRINT statements. Let us do that: WITH_DBUG_TRACE=OFF
shall disable DBUG_PRINT() as well.

A few InnoDB recovery tests used to check that some output from
DBUG_PRINT("ib_log", ...) is present. We can live without those checks.

Reviewed by: Vladislav Vaintroub

 fts_sync_commit() fails to release the auxiliary table handle
when it encounters error. This issue is caused by
commit 1fd7d3a9(MDEV-25581).
fts_cache_clear() releases the auxiliary table handles.
MDEV-25581's patch clear the cache only if fts_sync_commit was
successful.

MDEV-28868 : wsrep_incoming_address status variable prints 0 as port number if the port is not mentioned in wsrep_node_incoming_address system variable

Problem was that mysqld_port is not set on set_ports() because
it will be executed later. Fix is naturally fall back to
MYSQL_PORT.

row_log_table_apply_update(): Free the pcur.old_rec_buf before returning.
It may be allocated by btr_pcur_store_position() inside
btr_blob_log_check_t::check() and btr_store_big_rec_extern_fields().

This memory leak was introduced in
commit 2e814d47 (MariaDB Server 10.2.2)
via mysql/mysql-server@ce0a1e85e24e48b8171f767b44330da635a6ea0a
(MySQL 5.7.5).

The fix for MDEV-29352 was pushed to 10.6+ but the code causing the
bug is old and the bug is unlikely to be a recent regression in 10.6.
So, we apply the fix also to older versions, 10.3-10.5.

The original commit message:

MDEV-29352 SIGSEGV's in strlen and unknown location on optimized builds at SHUTDOWN

When the UDF creation frails to write the newly created UDF into
the related system table, the UDF is still created in memory.

However, as it is now, the related DLL is unloaded in this case right
in the mysql_create_function. And failure happens when the UDF handle
is freed and tries to unload the respective DLL which is still unloaded.

When the UDF creation frails to write the newly created UDF into
the related system table, the UDF is still created in memory.

However, as it is now, the related DLL is unloaded in this case right
in the mysql_create_function. And failure happens when the UDF handle
is freed and tries to unload the respective DLL which is still unloaded.

Update the result of a ./mtr --ps-protocol test

The rpl_row_img_sequence test can fail on resource
constrained buildbot machines due to its high
space consumption. To reduce this footprint, the
test is split into three parts, one for each value
of the binlog_row_img variable.

when generating a query to send to a remote server, spider generates
new aliases for all tables in the query (at least in the group_by handler).
First it walks all the expressions and create a list of new table aliases
to use for each field. Then - in init_scan() - it actually generates the
query, taking for each field the next alias from the list.

It dives recursively into functions, for example, for func(f1) it'll
go in, will see the field f1 and append to the list the new name for
the table of f1. This works fine for non-aggregate functions and
for aggregate functions in the SELECT list. But aggregate functions
in the ORDER BY are always references to the select list, they never
need to be qualified with a table name. That is, even if there is a
field name as an argument of an aggregate function in the ORDER BY
it must not append a table alias to the list. Let's just skip
aggregate functions when analyzing ORDER BY for table aliases.

This fixes spider/bugfix.mdev_29008
(was observed on aarch64, x86, ppc64le, and amd64 --rr)

The test is unstable because 'UPDATE t SET b = 100' latches a page and
waits for 'upd_cont' signal in lock_trx_handle_wait_enter sync point, then
purge requests RW_X_LATCH on the same page, and then 'SELECT * FROM t
WHERE a = 10 FOR UPDATE' requests RW_S_LATCH, waiting for RW_X_LATCH
requested by purge. 'UPDATE t SET b = 100' can't release page latch as
it waits for upd_cont signal, which must be emitted after 'SELECT * FROM
t WHERE a = 10 FOR UPDATE' acquired RW_S_LATCH. So we have a deadlock,
which is resolved by finishing the debug sync point wait by timeout, and
the 'UPDATE t SET b = 100' releases it's record locks rolling back the
transaction, and 'SELECT * FROM t WHERE a = 10 FOR UPDATE' is finished
successfully instead of finishing by lock wait timeout.

The fix is to forbid purging during the test by opening read view in a
separate connection before the first insert into the table.

Besides, 'lock_wait_end' syncpoint is not needed, as it enough to wait
the end of the SELECT execution to let the UPDATE to continue.

* MDEV-29426 Fix memory leak in CONNECT JSON/BSON

If information is being gathered on JSON/BSON tables we leak the heap
allocated to the table class. With this fix we close and cleanup
instead, just as we do for XML tables.

The reason why mysql/mysql-server@8020cfac20c55a870a874446870d5e90bdc181ed
split the files was some unit tests that never existed in the
MariaDB Server code base. The storage/innobase/unittest/ works just fine
with this file.

This is reverting part of 2e814d47
which applied InnoDB changes from MySQL 5.7.9.

The futex system calls were introduced in Linux 2.6.0,
which was released in December 2003. It should be safe to assume
that the system calls are always available on the Linux kernels
that MariaDB Server 10.3 would run on.

There should be no point to disable branch prediction hints or prefetch.