use waitable_task.wait() function to wait for the end of previous purge

The shutdown time assert was caused by untimely deactivation of
the binlog background thread and related structs destruction.
It could specifically occur when a transaction is replication unsafe
and has to be completed with a ROLLBACK event in binlog.

This gets fixed with the binlog background thread stop relocation
to a point and user transactions have been completed.
A test case is added to binlog.binlog_checkpoint which
also receives as a bonus a minor correction to reactivate a MDEV-4322 test
case that originally required a shutdown phase (that ceased to do).

In commit 8f8ba758 (MDEV-27234)
the data dictionary recovery was changed to use READ COMMITTED
so that table-rebuild operations (OPTIMIZE TABLE, TRUNCATE TABLE,
some forms of ALTER TABLE) would be recovered correctly.

However, for operations that avoid a table rebuild thanks to
being able to instantly ADD, DROP or reorder columns, recovery
must use the READ UNCOMMITTED isolation level so that changes to
the hidden metadata record can be rolled back.

We will detect instant operations by detecting uncommitted changes
to SYS_COLUMNS in case there is no uncommitted change of SYS_TABLES.ID
for the table. In any table-rebuilding DDL operation, the SYS_TABLES.ID
(and likely also the table name) will be updated.

As part of rolling back the instant ALTER TABLE operation, after the
operation on the hidden metadata record has been rolled back, a rollback
of an INSERT into SYS_COLUMNS in row_undo_ins_remove_clust_rec() will
invoke trx_t::evict_table() to discard the READ UNCOMMITTED definition
of the table. After that, subsequent recovery steps will load and use
the correct table definition.

Reviewed by: Thirunarayanan Balathandayuthapani
Tested by: Matthias Leich

Use suspend thread syncpoint instead of include/wait_condition.inc to
make sure DELETE created waiting lock before the next UPDATE begins
locking.

The ASAN report was made in the parallel slave execution of a query
event and implicitly involved (so also parallelly run) Format-Description
event.
The Query actually had unexpected impossible dependency on a preceding
"old" FD whose instance got destructed, to cause the ASAN error.

The case is fixed with storing the FD's value into Query-log-event
at its instantiating on slave. The stored value is from the very
FD of the Query's original binlog so remains to be correct
at the query event applying.

The branch C. of a new rpl_parallel_29322.test also demonstrates
(may need few --repeat though) the bug in its simple form of the same
server version binlog.

mtr supports running processes in background on Windows since 10.8.
Rename shutdown_not_windows.test to shutdown_debug.test, and allow this
test everywhere.

# Conflicts:
#	sql/sql_connect.cc
#	sql/threadpool_common.cc

# Conflicts:
#	sql/sql_connect.cc

Do not repeat yourself.

Instead of having the same DBUG_EXECUTE_IF code in threadpool and
thread-per-connection, add this code to setup_connection_thread_globals()
which is executed in all scheduling modes.

Correct some Salsa-CI upgrade test topics that are wrong
(like having mariadb-10.8 in name) and reword them to
look similar

MariaDB 10.9 Salsa-CI file is missing upgrade test from
10.8 and also upon 10.9. Add it to Salsa-CI file be congruence.

Additional fixes for 10.6:

fts_sync_commit(): Release cache->lock also on rollback.

fts_sync_write_words(): Avoid a crash if an error occurs,
by stopping at the first error.

fts_add_doc_by_id(): Sync the doc id only after adding the doc id
to the cache.

Let us specify STATS_AUTO_RECALC=0 for the failing section of the test.
It is possible that this test started failing sporadically ever since
commit 9608773f was applied and
tests no longer globally disable the InnoDB persistent statistics.

trx_undo_rseg_free(): Revert an inadvertent change that was done
as part of the merge a42c80bd

- During shutdown, InnoDB fts fails to update synced doc id
when there is only one doc id about to sync. While starting
the server, InnoDB fetches the already synced doc id from
config table. In the subsequent sync operation, InnoDB fails
with DB_DUPLICATE_KEY error.

In commit 244fdc43 (MDEV-29438)
we made sure that if the preceding record is the page infimum record,
no more than 8 bytes will be read from it. But, if the data payload of
the being-inserted record is less than 8 bytes (this can happen in
secondary indexes), we must not compare all 8 bytes.

This was caught by a failure of the test gcol.innodb_virtual_basic
under MemorySanitizer and some builds with AddressSanitizer.

- This is caused by commit 1bd681c8(MDEV-25506)
InnoDB removes the index from the table object before freeing the
leaf and non-leaf segments.

The resources like uring in MariaDB aren't intended for spawned
processes so we restrict access using the io_uring_ring_dontfork
liburing library call.