rpl.rpl_semi_sync_cond_var_per_thd could sporadically fail with
ER_NET_READ_ERROR, which was not suppressed in the test.

This patch adds the test suppression for that error.

The slave IO threads could not connect to their primaries due
to failing an SSL cert check.

Fixed by adding master_ssl_verify_server_cert=0 to the
change master commands.

 * rpl.rpl_get_lock failed due to missing piece of MDEV-33582
   commit which logs messages in extra detail when
   log_warnings > 3 (and this test uses log_warnings=4).

 * rpl.rpl_mdev33798 failed due to SSL cert failure when
   manually connecting slave2 to slave3 via change master. Fixed
   by adding master_ssl_verify_server_cert=0.

C/C 3.4 disables mysql_old_password by default, so

add an option for the `connect` command to support specifying
allowed authentication plugins (MARIADB_OPT_RESTRICTED_AUTH).

use it to enable mysql_old_password when needed for testing

it no longer supports TLSv1.0

disable view protocol (DROP VIEW doesn't work very well with transactions)
and cosmetic cleanups

(Based on original patch by Oleksandr Byelkin)

Multi-table DELETE can execute via "buffered" mode: at phase #1 it collects
rowids of rows to be deleted, then at phase #2 in multi_delete::do_deletes()
it calls handler->rnd_pos() to read rows to be deleted and deletes them.

The problem occurred when phase #1 used Rowid Filter on the table that
phase #2 would be deleting from.
In InnoDB, h->rnd_init(scan=false) and h->rnd_pos() is an index scan over PK
under the hood. So, at phase #2 ha_innobase::rnd_init() would try to use the
Rowid Filter and hit an assertion inside ha_innobase::rnd_init().

Note that multi-table UPDATE works similarly but was not affected, because
patch for MDEV-7487 added code to disable rowid filter for phase #2 in
multi_update::do_updates().

This patch changes the approach:
- It makes InnoDB not use Rowid Filter in rnd_pos() scans: it is disabled in
  ha_innobase::rnd_init() and enabled back in ha_innobase::rnd_end().
- multi_update::do_updates() no longer disables Rowid Filter for phase#2 as
  it is no longer necessary.

the test failed almost always in release (but not in debug) builds with

--- galera_sst_mariabackup.result
+++ galera_sst_mariabackup.reject
@@ -5,7 +5,7 @@
 connection node_1;
 select @@innodb_undo_tablespaces;
 @@innodb_undo_tablespaces
-0
+3
 connection node_2;
 select @@innodb_undo_tablespaces;
 @@innodb_undo_tablespaces

and

[Warning] InnoDB: Cannot change innodb_undo_tablespaces=0 because previous shutdown was not with innodb_fast_shutdown=0

because mariadbd *before this test* wasn't using innodb_fast_shutdown=0

Fix the bootstrap to use innodb_fast_shutdown=0 (and the bootstrap
creates a starting point for any test that uses a .cnf file)

followup for cac0fc97

also, remove redundant include/have_innodb.inc

and fix installation of mysql.service on buster

followup for ec09c034

FreeBSD doesn't like it and hangs.

As we don't wait for signal handler, let's disable SIGHUP in bootstrap
too

.opt files, unlike combinations, accumulate, let's not overuse them

followup for 13663cb5

Makes easier to add new policy to the list, and merge to newer versions-

Workaround patch: Do not remove GROUP BY clause when it has
subquer(ies) in it.

remove_redundant_subquery_clauses() removes redundant GROUP BY clause
from queries in form:
  expr IN (SELECT no_aggregates GROUP BY ...)
  expr {CMP} {ALL|ANY|SOME} (SELECT no_aggregates GROUP BY ...)
This hits problems when the GROUP BY clause itself has subquer(y/ies).

This patch is just a workaround: it disables removal of GROUP BY clause
if the clause has one or more subqueries in it.

Tests:
- subselect_elimination.test has all known crashing cases.
- subselect4.result, insert_select.result are updated.
Note that in some cases results of SELECT are changed too (not just
EXPLAINs). These are caused by non-deterministic SQL: when running a
query like:

  x > ANY( SELECT col1 FROM t1 GROUP BY constant_expression)

without removing the GROUP BY, the executor is free to pick the value
of t1.col1 from any row in the GROUP BY group (denote it $COL1_VAL).
Then, it computes x > ANY(SELECT $COL1_VAL).

When running the same query and removing the GROUP BY:

   x > ANY( SELECT col1 FROM t1)

the executor will actually check all rows of t1.

The problem was two fold:
- REPAIR TABLE t1 USE_FRM did not work for transactional
  Aria tables (Table was thought to be repaired, which it was not) which
  caused issues in later usage of the table.
- When swapping tmp_data file to data file, sort_info files where not
  updated. This caused problems if there was several unique keys and
  there was a duplicate for the second key.

Due to this bug a wrong result might be expected from queries with
an IN subquery predicate in the WHERE clause and a derived table in the
FROM clause to which split optimization could be applied.

The function JOIN::fix_all_splittings_in_plan() used the value of the
bitmap JOIN::sjm_lookup_tables() such as it had been left after the
search for the best plan for the select containing the splittable
derived table. That value could not be guaranteed to be correct. So the
recalculation of this bitmap is needed to exclude the plans with key
accesses from SJM lookup tables.

Approved by Igor Babaev <igor@maridb.com>

Otherwise spider_direct_sql may still think the spider plugin is
available even after spider_db_done() was called.

Revert "MDEV-19949 mariabackup option of '--password' or '-p' without specifying password in commandline"

This reverts commit 91fb8b7f.

Incompatible change, see tests in the next commit

Reset the connection_name to contain a null string, if the pointer
points to the same space as that of the system variable
default_master_connection.

We do this because the system variable may be updated which could free
the pointer and create a new one, causing use-after-free for
re-execution of prepared statements and stored procedures where the
LEX may be reused.

This allows connection_name to be set again be to the system variable
pointer in the next call of this function (see earlier in this
function), after any possible updates to the system variable.

Additional changes for the galera_vote_rejoin_ddl test (for 10.5+).
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

The spider suite should --source include/start_slave.inc to make sure
the slave is up before proceeding.

In the absence of insight of the cause of spider.spider_fixes_part
failure as described in MDEV-30929, This is a workaround, which could
help narrow the possibility down to whether slave SQL thread attempts
to read from file that maybe not yet on disk. It does not otherwise
affect the coverage of the test.

I have pushed this commit 4 times, but have yet to encounter the
failure as described in MDEV-30929, so it could also fix the test and
stop the CI pollution.

Also replaced START SLAVE; with --source include/start_slave.inc
inside the slave_test_init.inc files.

When running on macOS, MTR will ask the operating system for the core count when --parallel=auto

MDEV-34085 Server crash ASAN used-after-poison upon 2nd execution of PS with erroneous timestamp conversion

The optimization code replacing DATETIME comparison to TIMESTAMP comparison
in conditions like:
- WHERE timestamp_col=const_expr
- WHERE const_expr IN (SELECT timestamp_column FROM t1)
worked as follows:

- Install an internal condition handler (suppressing and counting warnings).
- Convert const_expr from its data type to TIMESTAMP
- Check the warning count collected by the internal condition handler:
  * If any warnings happened during the constant conversion,
    then continue with DATETIME comparison.
  * Otherwise, go to the next stage of switching to TIMESTAMP comparison.

This scenario did not take into account that in some cases warnings
are escalated to errors. Errors were not caught by the internal handler,
so Type_handler_datetime_common::convert_item_for_comparison()
returned with an SQL error in the diagnostics area.
The calling code did not expect this.

Fixing the code to suppress and count both errors and warnings, to make sure
Type_handler_datetime_common::convert_item_for_comparison() returns without
adding any errors to DA if the conversion to TIMESTAMP fails and it decides
to go with DATETIME comparison.