ha_innobase::index_read(): If an autocommit non-locking transaction was
already started, refuse to access a SPATIAL INDEX.
Once a non-locking autocommit transaction has started, it must remain
in that mode (not acquire any locks).

This should fix one cause of the assertion failure that would occur in
DeadlockChecker::check_and_resolve() under heavy load, presumably
due to concurrent execution of trx_commit_in_memory().

Problem:
========
Aborting OPTIMIZE TABLE still logs in binary logs and replicates to the
Slave server. "Optimize table" command under execution, is killed by using
"Ctrl-C" as shown below.

MariaDB [test]> optimize table t2;
^CCtrl-C -- query killed. Continuing normally.

In spite of query execution being interrupted the query gets written to
binary log.

Analysis:
========
Admin command execution logic is not handling KILL command, hence it
ignores the KILL command and completes its execution.

Fix:
===
Check for thread killed notification, during admin command execution and
handle it. If thread kill occurs prior to any table modification the query
will not be written to binary log. If kill happens after at least one table
is modified then the query will be written to binary log. Ex: command in
execution is 'OPTIMIZE TABLE t1,t2' and the thread kill happens after t1
table is modified then 'OPTIMIZE TABLE t1,t2' will be written to binary log
as admin commands will not make the slave to diverge from master.

Problem:
=======
In slave_parallel_mode=optimistic configuration, when admin commands and
DML operation on the same table are scheduled simultaneously for execution,
it results in lock conflict and slave server either hangs due to
deadlock or goes down with an assert.

Analysis:
========
Admin commands OPTIMIZE, REPAIR and ANALYZE are written to binary log as
ordinary transactions. When 'slave_parallel_mode' is 'optimistic' DMLs are
allowed to run in parallel. But these locks are not detected by parallel
replication deadlock detection-and-handling mechanism. At times they result
in deadlock or assertion.

Fix:
===
Flag admin commands as DDL in Gtid_log_event at the time of writing to
binary log. Add a new bit EXECUTED_TABLE_ADMIN_CMD to
'm_unsafe_rollback_flags'. During 'mysql_admin_table' command execution it
accepts a list of tables to be processed and executes them in a loop. Upon
successful execution enable 'EXECUTED_TABLE_ADMIN_CMD' bit in
thd->transaction.stmt_unsafe_rollback_flags. Gtid_log_event constructor
will notice this flag and mark the current transaction with 'FL_DDL' flag.
Gtid_log_events marked as FL_DDL will not be scheduled parallel execution,
on the slave. They will execute in isolation to prevent deadlocks.

Note: Removed the call to 'trans_commit_implicit' from 'mysql_admin_table'
function as 'mysql_execute_command' will take care of invoking
'trans_commit_implicit'.

No longer a MySQL server, "his" is the wrong pronoun
for a server.

Thanks Michael Newton for highlighting these problems

Also changed slave -> replica.

1) This commit implements reading all sections from configuration
files while looking for the current value of any server variable,
which were previously only read from the [mysqld.suffix] group and
from [mysqld], but not from other groups such as [mariadb.suffix],
[mariadb] or, for example, [server].

2) This commit also fixes misrecognition of some parameters when
parsing a command line containing a special marker for the end
of the list of options ("--") or when short option names (such
as "-s", "-a" and "-h arg") chained together (like a "-sah arg").
Such parameters can be passed to the SST script in the list of
arguments after "--mysqld-args" if the server is started with a
complex set of options - this was revealed during manual testing
of changes to read configuration files.

3) The server-side preparation code for the "--mysqld-args"
option list has also been simplified to make it easier to change
in the future (if needed), and has been improved to properly
handle the special backquote ("`") character in the argument
values.

If a select query contained an ORDER BY clause that followed a LIMIT clause
or an ORDER BY clause or ORDER BY with LIMIT the EXPLAIN output for the
query showed an execution plan different from that was actually executed.

Approved by Roman Nozdrin <roman.nozdrin@mariadb.com>

Problem:- When slave is shutdown, we will get this assertion failure
sql/sql_list.h:642: void ilink::assert_linked(): Assertion `prev != 0
&& next != 0' failed.

Solution:- In close_connections when we call threads.get() it resets to
prev and next to NULL. And in parallel worker thread(handle_rpl_parallel_thread)
calls unlink_not_visible_thd() which assert on prev and next being not NULL.
.unlink_not_visible_thd() should be always called first before threads.get()
is called. To make sure worker calls unlink_not_visible_thd() in
slave_prepare_for_shutdown() we are deactivating the  worker thread pool
which in turn will close all worker threads. Since this is already done in 10.4
and 10.5 I am backPorting MDEV-20821 and MDEV-22370 to 10.2. Mdev-22370
is improving the MDEV-20821 patch.

MDEV-22370 safe_mutex: Trying to lock uninitialized mutex at /data/src/10.4-bug/sql/rpl_parallel.cc, line 470 upon shutdown during FTWRL

Problem:- When we issue FTWRL with shutdown in parallel, there is race between
FTWRL and shutdown. Shutdown might destroy the mutex (pool->LOCK_rpl_thread_pool)
before FTWRL can lock it. So we can get crash on FTWRL thread

Solution:- mysql_mutex_destroy(pool->LOCK_rpl_thread_pool) should wait for
FTWRL thread to complete its work , and then destroy.
So slave_prepare_for_shutdown will just deactivate the pool, and mutex is destroyed
later in end_slave()

Parallel slave server shutdown found to be hanging in
close_connections() triggered by shutdown due to a slave worker thread
would not be notified to exit in case the worker was sitting idle.

Fixed with destroying the worker pool earlier that is in
slave_prepare_for_shutdown() when all their driver threads have already left.
A test file is added to simulate the bug condition as well as check
multi-sourced and not-idle worker cases.

This commit contains a large set of further bug fixes and
improvements to SST scripts for Galera, continuing the work
that was started in MDEV-24962 to make SST scripts work smoothly
in different network configurations (especially using ipv6) and
with different environment settings:

 1) The ipv6 addresses were incorrectly handled in the SST script
    for rsync (incorrect address substitution for establishing a
    connection, incorrect address substitution for bind, and so on);
 2) Checking the locality of the ip-address in SST scripts did not
    support ipv6 addresses (such as "[::1]"), which were falsely
    identified as non-local ip, which further did not allow running
    two SSTs on different local addresses on the same machine.
    On the other hand, this bug masked some other errors (related
    to handling ipv6 addresses);
 3) The code for checking the locality of the ip address was different
    in the SST scripts for rsync and for mysqldump, with individual
    flaws. This code is now made common and moved to wsrep_sst_common;
 4) Waiting for the start of the transport channel (socat, nc, rsync,
    stunnel) in the wait_for_listen() and check_pid_and_port() functions
    did not process ipv6 addresses correctly in all cases (not for all
    branches);
 5) Waiting for the start of the transport channel (socat, nc, rsync,
    stunnel) in the wait_for_listen() and check_pid_and_port() functions
    for some code branches could give a false positive result due to
    the textual match of prefixes in the port number and/or PID of
    the process;
 6) Waiting for the start of the transport channel (socat, nc, rsync,
    stunnel) was supported through different utilities in SST scripts
    for mariabackup and for rsync, and with various minor flaws in
    the code. Now the code is still different in these scripts, but
    it supports a common set of utilities (lsof, ss, sockstat) and
    is synchronized across patterns that used to check the output
    of  these utilities;
 7) In SST via mariabackup, the signal about readiness to receive data
    is sometimes sent too early - immediately after listen(), and not
    after accept() (which are called by socat or netcat utility).
 8) Checking availability of the some options of some utilities was
    done using the grep pattern, which easily gives false positives;
 9) Common name (CN) for local addresses, if not explicitly specified,
    is now always replaced to "localhost" to avoid the need to generate
    many separate certificates for local addresses of one machine and
    not to depend on which the local address is currently used in test
    (ipv4 or ipv6, etc.);
10) In tests galera_sst_mariabackup_encrypt_with_key_server and
    galera_sst_rsync_encrypt_with_key_server the correct certificate
    is selected to avoid commonname (CN) mismatch problems;
11) Further refactoring to protect against spaces in file names.
12) Further general refactoring to eliminate bash-specific constructs
    or to improve code readability;
13) The code for setting options for the nc (netcat) utility was
    different in different scripts for SST - now it is made identical.
14) Fixed long-time broken encryption via xbcrypt in combination with
    mariabackup and added support for key-based encryption via openssl
    utility, which is now enabled by default for encrypt=1 mode (this
    default mode can be changed using a new configuration file option
    "encypt-format=openssl|xbcrypt", which can be placed in the [mysqld],
    [sst] or in the [xtrabackup] section) - this change will allow us
    to use and to test the encypt=1 encryption without installing
    non-standard third-party utilities.

This is incosistent with other single config generators, where
the default type has always been RelWithDebInfo.

Fixed by moving setting of CMAKE_BUILD_TYPE right before PROJECT.

unless explicitly overruled with -DWITH_JEMALLOC=no

XA transaction only allows to access data in specific states,
in ACTIVE, but not in IDLE or PREPARE.

But even then one should be able to run SHOW STATUS.

if mysqld is restarted during a test, the debugger script
should be reused or overwritten, but not appended to the existing file

mysqltest has no --gdb option

This reverts commit 72fa9dab

but doesn't recover deleted jars - they still exist in
mysql-test/connect/std_data, no need to have them twice.

Also it removes a redundant copy on JavaWrappers.jar

and configuration.

1. Pass joiner's authentication information to donor together with address
   in State Transfer Request. This allows joiner to authenticate donor on
   connection. Previously joiner would accept data from anywhere.

2. Deprecate custom SSL configuration variables tca, tcert and tkey in favor
   of more familiar ssl-ca, ssl-cert and ssl-key. For backward compatibility
   tca, tcert and tkey are still supported.

3. Allow falling back to server-wide SSL configuration in [mysqld] if no SSL
   configuration is found in [sst] section of the config file.

4. Introduce ssl-mode variable in [sst] section that takes standard values
   and has following effects:
    - old-style SSL configuration present in [sst]: no effect
      otherwise:
    - ssl-mode=DISABLED or absent: retains old, backward compatible behavior
      and ignores any other SSL configuration
    - ssl-mode=VERIFY*: verify joiner's certificate and CN on donor,
                        verify donor's secret on joiner
                        (passed to donor via State Transfer Request)
                        BACKWARD INCOMPATIBLE BEHAVIOR
    - anything else enables new SSL configuration convetions but does not
      require verification

    ssl-mode should be set to VERIFY only in a fully upgraded cluster.

    Examples:

    [mysqld]
    ssl-cert=/path/to/cert
    ssl-key=/path/to/key
    ssl-ca=/path/to/ca

    [sst]

     -- server-wide SSL configuration is ignored, SST does not use SSL

    [mysqld]
    ssl-cert=/path/to/cert
    ssl-key=/path/to/key
    ssl-ca=/path/to/ca

    [sst]
    ssl-mode=REQUIRED

     -- use server-wide SSL configuration for SST but don't attempt to
        verify the peer identity

    [sst]
    ssl-cert=/path/to/cert
    ssl-key=/path/to/key
    ssl-ca=/path/to/ca
    ssl-mode=VERIFY_CA

     -- use SST-specific SSL configuration for SST and require verification
        on both sides
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

1. Fix eval command line to correctly pass stunnel option to rsync on donor.
2. Deprecate `tkey`, `tcert` and `tca` options in [sst] section in favor of
   conventional `ssl-key`, `ssl-cert` and `ssl-ca`, but keep their precedence
   for backward compatibility.
3. Default to require SSL encryption if at least SSL key and cert files are
   specified in configuration, either in [sst] or [mysqld] sections.
4. Enable `verify*` option for stunnel on donor only if
   a. CA file is specified somewhere in the configuration
   b. it is explicitly requested in [sst] section by either specifying
   ssl-mode or CA file there. In this case if ssl-mode is not explicitly
   given, it defaults to VERIFY_CA.

   ssl-mode maps to stunnel options as follows:
   VERIFY_CA       -> verifyChain = yes
   VERIFY_IDENTITY -> verifyPeer = yes

   Example to require donor to verify joiner identity:
```
[mysqld]
ssl-cert=/path/to/cert
ssl-key=/path/to/key
ssl-ca=/path/to/ca

[sst]
ssl-mode=VERIFY_IDENTITY
```
5. If SSL verification is requested, joiner verifies donor by checking the
   secret passed to donor via SST request.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>

When you only need view structure, don't call handle_derived with
DT_CREATE and rely on its internal hackish check to skip DT_CREATE.
Because handle_derived is called from many different places,
and this internal hackish check is indiscriminative.

Instead, just don't ask handle_derived to do DT_CREATE
if you don't want it to do DT_CREATE.

When you only need view structure, don't call handle_derived with
DT_CREATE and rely on its internal hackish check to skip DT_CREATE.
Because handle_derived is called from many different places,
and this internal hackish check is indiscriminative.

Instead, just don't ask handle_derived to do DT_CREATE
if you don't want it to do DT_CREATE.

After switching to the new mariabackup interface (instead of
the outdated innobackupex interface, which is supported for
compatibility), we need to explicitly pass a path to the datadir
directory as a parameter, since in the new interface the value
of this option is not automatically set in such a way that it
always matches the SST/IST logic. This commit adds passing this
option as an explicit parameter to mariabackup. This commit also
removed unnecessary options that are not used and not supported
by mariabackup.

Also, numerous flaws in the common wsrep_sst_common script have
been fixed:

 1) There are many bash-specific constructs in the script that
    may not be supported by other interpreters, which can lead
    to the most unexpected errors during SST, because failures
    in the interpretation of bash-specific constructs lead to
    incorrect parsing of arguments;
 2) There is parse_cnf() function which is often called by other
    scripts for the "mysqld" or "--mysqld" group, but it does not
    take into account the default group suffix, which leads to
    reading values only from the default group, which then leads
    to errors due to reading the default values instead of the
    values for a specific group;
 3) Some options such as --user, --innodb-data-home-dir or --datadir
    are not removed from the --mysqld-args list, although they are
    processed inside scripts (and passing of these options funther
    may cause problems for mariabackup);
 4) If an argument that the script understands is present in
    the --mysqld-args list twice, then this causes SST to fail,
    instead of reading the most recent value;
 5) The "--host" parameter is technically still supported among
    the arguments of the SST scripts, but in reality scripts do not
    work with it as expected, especially if it has an IPv6 address;
 6) If the port number is absent in the --address parameter value,
    but the port number is explicitly passed through the --port
    argument, then the scripts for mariabackup and xtrabackup-v2
    fail;
 7) If a new address interface is used (with the --address parameter),
    then automatic default port substitution is not performed, although
    it is supported for the legacy --host/--port interface.
 8) If there are spaces in the parameter values after --mysqld_args,
    then their further transfer does not occur correctly, which
    causes mariabackup to fail during SST - the space splits
    the argument in such a way that it breaks the parsing of the
    following parameters;
 9) If most of the parameters that are names or paths to the files
    or directories contain spaces, then SST scripts fail in an
    unpredictable way due to incorrect variable substitutions;
10) If the --log-bin option is passed among the arguments of myqlds
    (--mysqld-args) without a parameter, and the --binlog option
    is not specified, then the script cannot substitute the default
    name for binlog and cannot construct binlog name using the
    --log-basename argument (which is against server specifications);
11) Tail slashes are not removed from the directory names, which,
    upon further substitution, leads to the appearance of a double
    slash in the file paths;
12) The explicit --binlog parameter (which is now always transmitted
    from the server side) and the "hidden" --log-bin parameter in the
    list of arguments after --mysqld-args are perceived as two different
    parameters in different parts of the scripts, and if they are do not
    match for some reason, this will lead to failures during SST;

Also, all new changes from the 10.6 branch have been migrated here,
including the latest pull requests for authentication (only the part
that concerns SST scripts).

It also fixes dozens of other bugs in all SST scripts.

Removed numerous extra blank lines and spaces that interfere with
reading and understanding program code, making it more difficult to
find errors in scripts. I also removed all extra trailing spaces at
the ends of lines, which lead to marking extra lines as changes
(in subsequent changes). The amount of indentation in some parts
of the code has also been normalized.

Fix a race condition in the testcase. The testcase assumed that
State='Sending data' means that the thread is already in an
InnoDB lock wait. This is not case, there is a gap between the
state changing to Sending data and execution reaching the point
where it is waiting for a lock.

Use a more precise check instead, through I_S.INNODB_TRX.

Problem:
========
180511 11:07:58 [ERROR] Slave I/O: Unexpected master's heartbeat data:
heartbeat is not compatible with local info;the event's data: log_file_name
mysql-bin.000009 log_pos 1054262041, Error_code: 1623

Analysis:
=========
In replication setup when master server doesn't have any events to send to
slave server it sends an 'Heartbeat_log_event'. This event carries the
current binary log filename and offset details. The offset values is stored
within 4 bytes of event header. When the size of binary log is higher than
UINT32_MAX the log_pos values will not fit in 4 bytes memory.  It overflows
and hence slave stops with an error.

Fix:
===
Since we cannot extend the common_header of Log_event class, a greater than
4GB value of Log_event::log_pos is made to be transported with a HeartBeat
event's sub-header.  Log_event::log_pos in such case is set to zero to
indicate that the 8 byte sub-header is allocated in the event.

In case of cross version replication following behaviour is expected

OLD - Server without fix
NEW - Server with fix

OLD<->NEW : works bidirectionally as long as the binlog offset is
            (normally) within 4GB.

When log_pos > UINT32_MAX
OLD->NEW  : The 'log_pos' is bound to overflow and NEW slave may report
            an invalid event/incompatible heart beat event error.
NEW->OLD  : Since patched server sets log_pos=0 on overflow, OLD slave will
            report invalid event error.

- Fixing post-push failure of innodb_fts_misc_1 test case.

InnoDB tries to fetch the deleted doc ids for discarded
tablespace. In i_s_fts_deleted_generic_fill(), InnoDB needs
to check whether the table is discarded or not before fetching
deleted doc ids.