Calling a stored function that uses a cursor inside its body
could produce the error ER_NO_SUCH_TABLE on the second execution
in case the cursor uses multi-table query and one of the tables
is a temporary table just created before querying the cursor and
dropped just after the query has been executed.

The reason for issue is that re-parsing of failed a SP instruction
caused be create/drop of the temporary table used LEX object
left from previous parsing of a SP instruction's query instead
re-initialize the lex object before parsing.

To fix the issue, add initialization of lex for cursor's
statement before re-parsing the query of a failed SP instruction.

Several points of synchronization during ALTER TABLE COPY looked identical
in the progress report query. Besides, if its the late lock upgrade stage,
the data would be:
STAGE   0
MAX_STAGE       0
PROGRESS        0.000

which looks irrelevant.

This patch moves thd_progress_deinit call after the last lock upgrade.

Also, for online alter, if there is nothing to replicate, the
progress and max_progress values would be 0, which discard the result data
on the side of sql_show, see processlist_callback in sql_show.cc.
So now the minimal max_progress will be 1. To avoid 0% progress in the
report, minimax progress value is also set to 1, so we will see 100% if
there's nothing to replicate.

FMT_STATIC_THOUSANDS_SEPARATOR stopped working in 10.0.0
Let's not use this fmt version for now

even if pkg-config has it. otherwise build dependencies
aren't detected.

After MDEV-32551, in a master/slave setup, if the replica's IO thread
quickly and successively reconnects (i.e quickly running
STOP SLAVE IO_THREAD followed by START SLAVE IO_THREAD), the relay log
rotation behavior changes. That is, MDEV-32551 changed the logic of the
binlog_dump_thread on the primary, such that it can stop itself before
sending any events if it sees a new connection has been created to a
replica with the same server_id. Pre MDEV-32551, the connection would
establish and it would send a "fake" rotate event to populate the
log name. Post MDEV-32551, the connection stops itself, and a rotate
event is not sent.

This made the test rpl.rpl_mariadb_slave_capability unstable because
it is reliant on the name of the relay logs (which is dependent on the
number of rotates); and the pre-amble of the test would quickly
start/stop the IO thread. There a binlog dump thread could end itself
before sending a rotate event to the replica, thereby changing the name
of the relay log.

This patch fixes this by adding in a synchronization in-between IO thread
restarts, such that it waits for the primary's binlog dump threads to
sync up with the state of the replica.

This will allow selects pass until the rename/commit stage.
The lock is anyway upgraded to MDL_EXCLUSIVE later by the
wait_while_table_is_used call in mysql_alter_table.

test disabled, until fixed

rpl.rpl_seconds_behind_master_spike uses the DEBUG_SYNC mechanism to
count how many format descriptor events (FDEs) have been executed,
to attempt to pause on a specific relay log FDE after executing
transactions. However, depending on when the IO thread is stopped,
it can send an extra FDE before sending the transactions, forcing
the test to pause before executing any transactions, resulting in a
table not existing, that is attempted to be read for COUNT.

This patch fixes this by no longer counting FDEs, but rather by
programmatically waiting until the SQL thread has executed the
transaction and then automatically activating the DEBUG_SYNC point
to trigger at the next relay log FDE.

The memory leak occurs on error when backup_reset_alter_copy_lock fails
with timeout. This leads to the alter rollback, but flush_unused is not
called.

Move table flushing on error handling to a single place and mind more
possible failures this time.

A second DML in a transaction for a table of non-rollbackable engine
leads to a cache corruption, because the cache wasn't reset after a
statement end, but also wasn't destroyed.

This patch resets the cache for a reuse by subsequent statements in
current transaction.

32bit uses less memory so the test for max_memory_usage does not work

This caused some crashes on 32 bit platforms.

A debug_sync signal could remain for the SQL thread that should have begun
a wait_for upon seeing a GTID event, but would instead see the old signal
and continue on without waiting. This broke an "idle" condition in
SHOW SLAVE STATUS
which should have automatically negated Seconds_Behind_Master. Instead,
because the SQL thread had already processed the GTID event, it set
sql_thread_caught_up to false, and thereby calculated the value of
Seconds_behind_master, when the test expected 0.

This patch fixes this by resetting the debug_sync state before creating a
new transaction which sends a GTID event to the replica

Let us suppress this timing-sensitive warning globally.
We added it in commit d34479dc (MDEV-33053)
so that in case InnoDB hangs due to running out of buffer pool, there
would be a warning about it. On a heavily loaded system that is running
with a small buffer pool, these warnings may be occasionally issued
while page writes are in progress.

With this patch, 4-component MSI version can be used, e.g by setting
TINY_VERSION variable in CMake, or by adding a string, e.g
MYSQL_VERSION_EXTRA=-2
which sets TINY_VERSION to 2, and also changes the package name.

The 4-component MSI versions do not support MSI major upgrades, only minor
ones, i.e do not reinstall components, just update existing ones based
on versioning rules.

To support these rules, add DefaultVersion for the files that won't
otherwise be versioned - headers, static and import libraries,
pdbs, text - xml, python and perl scripts Also silence WiX warning
that MSI won't store hashes for those files anymore.

Testing exit code from popen(), comparing it with 1, and deciding that
perl.exe is not there, is a) wrong conclusion, and b) uninteresting,
because MTR always runs with perl, and with MTR_PERL set.

Background:
Recent change in 7af50e4d introduced
exit code 1 from perl snippet, that broke Windows CI. Do not want
to debug this ever again.

There are two array fields in spider_share with similar names:

share->use_sql_dbton_ids that maps from i to the i-th dbton used by
share. Thus it should be used only when i iterates over all distinct
dbtons used by share.

share->sql_dbton_ids that maps from i to the dbton used by the i-th
link of the share. Thus it should be used only when i iterates over
all links of a share.

We correct instances where share->sql_dbton_ids should be used instead
of share->use_sql_dbton_ids.