Rollback is not supposed to fail. This prevents false failures in
spider rollback.

MDEV-31788 Factor functions to reduce duplication around spider_check_and_init_casual_read in ha_spider.cc

factored out static functions:
- spider_prep_loop
- spider_start_bg
- spider_send_queries

They are for unnecessary debugging purposes only.

The functions called in blocks protected by this macro remain
undefined as of 11.5 c96b23f9

It's virtually empty now

Show::Column() was added in MDEV-19772
4156b1a2

handler::pre_calculate_checksum was added in MDEV-16249
be5c432a

get_negated() was introduced in MDEV-16707

sql_cache was moved to lex in MDEV-11953 in
de745ecf

{STRING|INT|REAL|DECIMAL|DATE}_ITEM were replaced with CONST_ITEM in
MDEV-14630 c20cd68e

MDEV-16246 was fixed long ago. And this macro was removed in other
versions too

handler::need_info_for_auto_inc() was added in MDEV-7720 / MDEV-7726
in commit dc17ac16

This macro is unused, and not in 11.5 c96b23f9

This macro is unused

The flag argument was added to handler::start_bulk_insert() in
the MDEV-539 commit
ca2cdaad

new_data is const since at least 2017: a05a610d

handler has can_use_for_auto_inc_init() since at latest 2017:
dc17ac16

HA_EXTRA_USE_CMP_REF is undefined, and remains so as of 11.5
c96b23f9

HA_EXTRA_STARTING_ORDERED_INDEX_SCAN was added latest 2018:
921c5e93

net has thd since 2015 in 56aa1998 for MDEV-6152

arg_count was protected since 2015 in commit
afa17734

unifdef -DSPIDER_HAS_HASH_VALUE_TYPE -m storage/spider/spd_* storage/spider/ha_spider.* storage/spider/hs_client/*

New runtime diagnostic introduced with MDEV-34490 has detected
that `Item_int_with_ref` incorrectly returns an instance of its ancestor
class `Item_int`. This commit fixes that.

In addition, this commit reverts a part of the diagnostic related
to `clone_item()` checks. As it turned out, `clone_item()` is not required
to return an object of the same class as the cloned one. For example,
look at `Item_param::clone_item()`: it can return objects of `Item_null`,
`Item_int`, `Item_string`, etc, depending on the object state.
So the runtime type diagnostic is not applicable to `clone_item()` and
is disabled with this commit.

As the similar diagnostic failures are expected to appear again
in the future, this commit introduces a new test file in the main suite:
item_types.test, and new test cases may be added to this file

Reviewer: Oleksandr Byelkin <sanja@mariadb.com>

When mysqldump is run to dump the `mysql` system database, it generates
INSERT statements into the table `mysql.gtid_slave_pos`.
After running the backup script
those inserts did not produce the expected gtid state on slave. In
particular the maximum of mysql.gtid_slave_pos.sub_id did not make
into
   rpl_global_gtid_slave_state.last_sub_id

an in-memory object that is supposed to match the current state of the
table. And that was regardless of whether --gtid option was specified
or not. Later when the backup recipient server starts as slave
in *non-gtid* mode this desychronization may lead to a duplicate key
error.

This effect is corrected for --gtid mode mysqldump/mariadb-dump only
as the following.  The fixes ensure the insert block of the dump
script is followed with a "summing-up" SET @global.gtid_slave_pos
assignment.

For the implemenation part, note a deferred print-out of
SET-gtid_slave_pos and associated comments is prefered over relocating
of the entire blocks if (opt_master,slave_data &&
do_show_master,slave_status) ...  because of compatiblity
concern. Namely an error inside do_show_*() is handled in the new code
the same way, as early as, as before.

A regression test can be run in how-to-reproduce mode as well.
One affected mtr test observed.
rpl_mysqldump_slave.result "mismatch" shows now the new deferring print
of SET-gtid_slave_pos policy in action.

Additional tests for MDEV-28345 ASAN: use-after-poison or unknown-crash in my_strtod_int from charset_info_st::strntod or test_if_number

The test was missing a save_master_gtid.inc on the master,
leading to the slave thinking it was in sync after executing
sync_with_master_gtid.inc, despite not having executed the
latest transaction. This skipped transaction, XA COMMIT,
was supposed to error-to-be-ignored because its XID could not
be found, but be thrown out because the replication filters
would filter out the target database. However, if the slave
was able to stop before executing the transaction, then
the replication filer is reset (to empty), and when the
slave is later restarted, that transactions error would
no longer be ignored.

Additionally, as the test cases added in MDEV-33921 rely
on GTID synchronization, the test cases now force
master_use_gtid=slave_pos for consistency

This reverts commit 938b9293. Not needed after 90d376e0.

quote a database name in the slow log

remove it

refine mariadb-backup password zapping check