this should simplify run-time cluster management

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.

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

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.

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.

win

Fixed by the author in other way (char -> short)

This reverts commit 496f7090.

Since 2017 (c2118a08) THD::awake() no longer requires LOCK_thd_data.
It uses LOCK_thd_kill, and this latter mutex is used to prevent
a thread of dying, not LOCK_thd_data as before.

and it is that important to be run every time

innodb_shutdown(): Check that fil_system.temp_space is not null
before invoking a member function.

This regression was caused by the merge
commit fa1aef39
of MDEV-24340 (commit 1eb59c30).

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

Skipping the package within debian/rules won't work because starting
with Debian 10, the helper scripts read the control file before the
recipe.

bson.cpp:1775:3: error: case label value is less than minimum value for type [-Werror]
   case TYPE_NULL:
bson.cpp:1776:7: error: statement will never be executed [-Werror=switch-unreachable]
     b = true;