- Fixes building with galera and tokudb
- Added support for --without-wsrep BUILD script option

- Backport from 10.4

According to close(2) "Retrying the close() after a failure return is
the wrong thing to do"

Corrects 5c81cb88 in MDEV-15635

Make ALGORITHM=INSTANT explicit.

Store original charset during client authentication, and restore it for
COM_RESET_CONNECTION

No need to lowercase table names on case-sensitive file systems, as the
cache won't contain the 'lowercased' table anyway. And it prevents the
UPPERCASE.frm from being deleted.

Problem:
=======
Mariabackup incremental prepare creates new tablespace when it encounter
new tablespace. It sets the intial size as FIL_IBD_FILE_INITIAL_SIZE (4).
But while applying redo log, it tries to access 5th page and then
it leads to out of tablespace error.

Fix:
===
While parsing the redo log record, track FSP_SIZE in recv_spaces for the
respective space id. Assign the recv_size for the tablespace when it
is loaded. Extend the tablespace depends on recv_size while applying
the redo log record.

- Added retry logic if validation of first page fails with checksum
mismatch.

Do not try to write ER_SHUTDOWN error message to socket, when it is forcefully closed by the shutdown.
This will avoid the race condition (attempt to write to closed socket,  if connection shuts down by itself).

MDEV-18426: Most of the mtr tests in the galera_3nodes suite fail

add simplified slave_trx_isolation.test

add simplified quick_mode.test

Add a system variable spider_slave_trx_isolation.
- spider_slave_trx_isolation
  The transaction isolation level when Spider table is used by slave SQL thread.
  -1 : OFF
   0 : READ UNCOMMITTED
   1 : READ COMMITTED
   2 : REPEATABLE READ
   3 : SERIALIZABLE
  The default value is -1

Miscellaneous Spider typos

Change default value of the followings
quick_mode 0 -> 3
quick_page_size 100 -> 1024

Add the following parameter for limiting result page size by byte
- quick_page_byte(qpb)
  Number of bytes in a page when acquisition one by one.
  When quick_mode is 1 or 2, Spider stores at least 1 record even if
  quick_page_byte is smaller than 1 record. When quick_mode is 3,
  quick_page_byte is used for judging using temporary table.
  That is given to priority when server parameter spider_quick_page_byte
  is set.
  The default value is 10485760

Fix "out of sync" issue at using quick_mode = 1 or 2

The fields of the temporary table were not created in create_tmp_table function. Because item->const_item() was true. But the temporary tables that is created by Spider are always used all columns. So Spider should call create_tmp_table function with TMP_TABLE_ALL_COLUMNS flag.

Most of the mtr tests in the galera_3nodes suite fail
for a variety of reasons with a variety of errors.
Some tests simply need to add the missing "connection"
lines to the result files, but many of them fail due
to substantial errors that require reworking test files.

This patch adds the missing "connection" lines to
the result files and fixes several substantial flaws
in the galera_3nodes suite tests and in the mtr framework
service files, adapting the tests from galera_3nodes
for the current version of MariaDB.

https://jira.mariadb.org/browse/MDEV-18426

Analysis:
========
Increasing the length of the indexed varchar column is not an instant operation for
innodb.

Fix:
===
- Introduce the new handler flag 'Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH' to
indicate the index length differs due to change of column length changes.

- InnoDB makes the ALTER_COLUMN_INDEX_LENGTH flag as instant operation.

This is a port of Mysql fix.

    commit 913071c0b16cc03e703308250d795bc381627e37
    Author: Nisha Gopalakrishnan <nisha.gopalakrishnan@oracle.com>
    Date:   Wed May 30 14:54:46 2018 +0530

        BUG#26848813: INDEXED COLUMN CAN'T BE CHANGED FROM VARCHAR(15)
                      TO VARCHAR(40) INSTANTANEOUSLY

The parameters innodb_file_format and innodb_large_prefix were overridden
in the Debian-distributed configuration files, because the default values
of these parameters between MariaDB 5.5 and MariaDB 10.2
did not make any sense.

To allow a more seamless upgrade from MariaDB 10.1 to later versions,
let InnoDB recognize the parameters innodb_file_format and
innodb_large_prefix and issue deprecation warnings for them if they
are specified. A deprecation period of only one major release
(one year between the MariaDB 10.2 and 10.3 releases) is insufficient
for these widely used parameters.

MDEV-15740 Fixes to Galera transaction recovery

If the TC log did not provide list of XIDs to recover, the
commit by XID was skipped during wsrep recovery if binlog emulation
was on. However, with wsrep we want to commit every prepared transaction
with assigned wsrep XID since the transaction has already been
committed in the cluster.

Added a special condition to always proceed to commit by XID in
xarecover_handlerton() if binlog is off and the recovered transaction
has wsrep XID.

and gitignore myrocks_hotbackup (as it's now generated)

Closes #1081

Closes #1080

It's too late. Might work or not (and on buster it doesn't).

MDEV-18057 Assertion `(node->state == 5) || (node->state == 6)' failed in row_upd_sec_step upon DELETE after UPDATE failed due to FK violation

The idea of the fix: reset state from previous query.

row_upd_clust_step(): reset cached index before updating a clustered index

Closes #1133

Clear wsrep XID in innobase_rollback_by_xid() for recovered wsrep
transaction in order to avoid resetting XID storage when rolling back
wsrep transaction during recovery.

Sort wsrep XIDs read from storage engine in ascending order and
erify that the range is continuous during crash recovery. If binlog is off,
commit all recovered transactions for continuous seqno range. This is safe
because all transactions with wsrep XID have been certified and must be
committed in the cluster. On the other hand if binlog is on, respect binlog
as a transaction coordinator in order to avoid missing transactions in binlog
that have been committed into storage engine .

Backported wsrep-recover test from 10.4 to test the wsrep recovery
after database shutdown or crash. Renamed the test to wsrep-recover-v25
to avoid conflicts with existing test in 10.4 and to provide coverage
for wsrep-API v25 compatible behavior.

The test case in 10.2 is simpler because out of order prepare
step cannot happen, the commit order critical section is grabbed
before prepare phase.

Test is not recorded since it does not produce expected result.