Save / restore auto_increment_offset in test galera_gcs_fragment

MDEV-15794 Fix and re-enable test galera_var_retry_autocommit

MDEV-13549 Record and re-enable galera_ist_mysqldump

Test galera_gcs_fragment performs cluster reconfiguration, so
`auto_increment_offset` may change, and check test case at the
end of test fails.

The test assumes that `@@global.auto_increment_offset` is equal to
`wsrep_local_index + 1`. Which is normally the case if galera runs
with option `wsrep_auto_increment_control` enabled.
However, if some prior test performs a restart of a server, then
`wsrep_local_index` may change, and galera will set the value of
`auto_increment_offset` accordingly.
However, if `auto_increment_offset` changes during a test run, then
mtr will complain. To avoid that, tests that perform restarts include
`auto_increment_offset_save.inc` and `auto_increment_offset_restore.inc`.
Which reset the value of `auto_increment_offset`. And when that
happens, `auto_increment_offset` will no longer be equal to
`wsrep_local_index + 1`, and the test fails.
To avoid this problem, simply check that the offsets are different
on the nodes that compose the cluster.

MDEV-16005 sporadic failures with galera tests MW-328B and MW-328C

In commit e7f4e61f
the call fil_flush_file_spaces(FIL_LOG) is necessary.
Tablespaces will be flushed as part of the redo log
checkpoint, but the redo log will not necessarily
be flushed, depending on innodb_flush_method.

Test works after fixes for galera_sst_mysqldump.

The test was not deterministic and would occasionally fail, due to the
use of `sleep`.
This patch is a complete rewrite of the test using proper sync points.

Disable general log while truncating mysql.general_log to
avoid queries to be inserted there.

MDEV-16006 Fix test galera_kill_nochanges

MDEV-15811 Fix and re-enable test galera.galera_pc_ignore_sb

The test performs a restart and while doing so it occasionally
fails with "Server did not transition to READY state" in
`include/start_mysqld.inc".
Fix is to wait for the cluster to shrink before restarting
the node.

These test can sporadically show mutex deadlock warnings between LOCK_wsrep_thd
and LOCK_thd_data mutexes. This means that these mutexes can be locked in opposite
order by different threads, and thus result in deadlock situation.
To fix such issue, the locking policy of these mutexes should be revised and
enforced to be uniform. However, a quick code review shows that the number of
lock/unlock operations for these mutexes combined is between 100-200, and all these
mutex invocations should be checked/fixed.

On the other hand, it turns out that LOCK_wsrep_thd is used for protecting access to
wsrep variables of THD (wsrep_conflict_state, wsrep_query_state), whereas LOCK_thd_data
protects query, db and mysys_var variables in THD. Extending LOCK_thd_data to protect
also wsrep variables looks like a viable solution, as there should not be a use case
where separate threads need simultaneous access to wsrep variables and THD data variables.

In this commit LOCK_wsrep_thd mutex is refactored to be replaced by LOCK_thd_data.
By bluntly replacing LOCK_wsrep_thd by LOCK_thd_data, will result in double locking
of LOCK_thd_data, and some adjustements have been performed to fix such situations.

* After killing one galera node with include/kill_galera,
  wait for cluster to shrink

* Remove unnecessary include/wait_until_connected_again.inc

xb_assign_undo_space_start(): Correctly pass the length of
the buffer, so that the file name will not be truncated.

dict_load_table_low(): When flagging an error, assign *table = NULL.
Failure to do so could cause a crash if an error was flagged when
accessing INFORMATION_SCHEMA.INNODB_SYS_TABLES.

MDEV-15948 Fix error "Lost connection to MySQL server..." in test gal…

While the test case crashes a MariaDB 10.2 debug build only,
let us apply the fix to the earliest applicable MariaDB series (10.0)
to avoid any data corruption on a table-rebuilding ALTER TABLE
using ALGORITHM=INPLACE.

innobase_create_key_defs(): Use altered_table->s->primary_key
when a new primary key is being created.

* Increased timeout counter in galera_wait_ready.inc

* Replaced useless include/wait_until_ready.inc after start_mysqld.inc
  in galera_st_*.inc with wait_condition on cluster size.

MDEV-15929 Fix lock wait timeout on `SELECT @@GLOBAL.WSREP_ON`

followup for a3c980b3

same change in Locked_tables_list::unlink_from_list(), otherwise
thd->locked_tables_list will keep pointers to a free'd TABLE if
prelocked under lock tables.

This fixes a crash in main.create_or_replace on debug Win builds
after bcb36ee2

do_stmt_close() is embedded-aware.

this fixes the failure of innodb.innodb_bug48024 --ps --embed

Test galera_sst_mysqldump often fails with error "2013: Lost connection
to MySQL server during query". The connection is lost after the test
restart one of the nodes. This happens because the server closes client
connections if it is joining a cluster through SST method mysqldump.
On unlucky runs of the test it is possible that mysqld is restarted,
and then mtr client is disconnected while it tries to determine if
galera is ready before going on with the test.
This patch rewrites galera_wait_ready.inc so that it is immune to
being disconnected.

MDEV-15456 Server crashes upon adding or dropping a partition in ALTER under LOCK TABLE after ER_SAME_NAME_PARTITION

ALTER TABLE ... ADD PARTITION modifies the open TABLE structure,
and sets table->need_reopen=1 to reset these modifications
in case of an error.

But under LOCK TABLES the table isn't get reopened, despite need_reopen.

Fixed by reopening need_reopen tables under LOCK TABLE.

bad merge

in a specially crafted invalid packet, one can get end_pos < pos here

disable online alter add primary key for innodb, if the
table is opened/locked more than once in the current connection

(see assert in ha_innobase::add_index())

test case

This patch fixes a lock wait timeout error on `SELECT @@GLOBAL.WSREP_ON`
in `wait_wsrep_ready.inc`:

```
--connection node_2
...
--source include/kill_galera.inc

--connection node_1
--source include/wait_until_connected_again.inc # This includes wait_wsrep_ready.inc

```

The problem is that on node_2, kill_galera.inc may return before
the node is killed. So node_1 may still see that node_1 is alive
and will attempt to sync wait when doing those `SELECT` statements.
But sync wait is doomed to fail given that node_1 is killed, hence
the lock wait timeout.
One possible fix is to disable wsrep_sync_wait before including
wait_until_connected_again.
However, it appears that including wait_until_connected_again is
not necessary at all in node_1, so this patch removes it altogether.

one cannot do keyread on spatial indexes.

Any expensive WHERE condition for a table-less query with
implicit aggregation was lost. As a result the used aggregate
functions were calculated over a non-empty set of rows even
in the case when the condition was false.