We keep the MySQL 5.7 backup-incompatible TRUNCATE TABLE
only in MariaDB Server 10.2. In 10.3 and later releases,
only the backup-friendly TRUNCATE will be available.

While MariaDB Server 10.2 is not really guaranteed to be compatible
with Percona XtraBackup 2.4 (for example, the MySQL 5.7 undo log format
change that could be present in XtraBackup, but was reverted from
MariaDB in MDEV-12289), we do not want to disrupt users who have
deployed xtrabackup and MariaDB Server 10.2 in their environments.

With this change, MariaDB 10.2 will continue to use the backup-unsafe
TRUNCATE TABLE code, so that neither the undo log nor the redo log
formats will change in an incompatible way.

Undo tablespace truncation will keep using the redo log only. Recovery
or backup with old code will fail to shrink the undo tablespace files,
but the contents will be recovered just fine.

In the MariaDB Server 10.2 series only, we introduce the configuration
parameter innodb_unsafe_truncate and make it ON by default. To allow
MariaDB Backup (mariabackup) to work properly with TRUNCATE TABLE
operations, use loose_innodb_unsafe_truncate=OFF.

MariaDB Server 10.3.10 and later releases will always use the
backup-safe TRUNCATE TABLE, and this parameter will not be
added there.

recv_recovery_rollback_active(): Skip row_mysql_drop_garbage_tables()
unless innodb_unsafe_truncate=OFF. It is too unsafe to drop orphan
tables if RENAME operations are not transactional within InnoDB.

LOG_HEADER_FORMAT_10_3: Replaces LOG_HEADER_FORMAT_CURRENT.

log_init(), log_group_file_header_flush(),
srv_prepare_to_delete_redo_log_files(),
innobase_start_or_create_for_mysql(): Choose the redo log format
and subformat based on the value of innodb_unsafe_truncate.

The test needs to be run with rocksdb_flush_log_at_trx_commit=1, otherwise
the changes do not survive a crash.

Add wait on second node.

Ensure that no redo log checkpoint occurs in a critical section
of a recovery test.

The test is shutting down InnoDB, corrupting a file, and finally
restarting InnoDB. Before the shutdown, the test created the table
and inserted some records. Before MDEV-12288, there would be no access
to the table after server restart, but after MDEV-12288 purge would
reset the transaction identifier after the INSERT, and this would
sometimes happen after the restart.

To make the test deterministic, wait for purge to complete before the
shutdown.

if thread specific memory is requested and current_thd is NULL.

Leave DBUG_ASSERT() in place, to check in DBUG version.

Make the testcase stable

The bug appears as a slave SQL thread hanging in
rpl_parallel_thread_pool::get_thread() while there are no slave worker
threads to awake it.

The reason of the hang is that at the parallel slave worker pool
activation the being stared SQL thread could read the worker pool size
concurrently with pool deactivation. At reading the SQL thread did not
employ necessary protection from a race.

Fixed with making the SQL thread at the pool activation first
to grab the same lock as potential deactivator also does prior
to access the pool size.

			table for purge thread

Problem:
=======
	Purge tries to fetch mdl lock for the whole table even though it tries
to open one of the partition. But table name length was wrongly set to indicate
the partition name too.

Solution:
========
- Table name length should identify the table name only not the partition name.

		table for purge thread

Problem:
=======
	Purge tries to fetch mdl lock for the whole table even though it tries
to open one of the partition. But table name length was wrongly set to indicate
the partition name too.

Solution:
========
- Table name length should identify the table name only not the partition name.

          and join_cache_level=6

This bug was fixed by the patch for mdev-17382 applied to 5.5.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

Change for the test case in 10.3: splitting must be turned off to preserve
the explain.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

           derived table / view by equality

Now rows of a materialized derived table are always put into a
temporary table before join operation. If BNLH is used to join this
table with the result of a partial join then both operands of the
join are actually put into main memory. In most cases this is not
efficient.
We could avoid this by sending the rows of the derived table directly
to the join operation. However this kind of data flow is not supported
yet.
Fixed by not allowing usage of hash join algorithm to join a materialized
derived table if it's joined by an equality predicate of the form
f=e where f is a field of the derived table.

Amend previous patch, so it works in all cases (also for "change user"
command, and for RESET CONNECTION in 10.3)

MDEV-17313 Data race in ib_counter_t

This warning come from a copy() operation of type:
memcpy(ptr, ptr+A, B), which is safe but produces a warning
when run with valgrind.

To avoid the warning, I added copy_or_move() method which uses
memmove() instead of memcpy().

In 10.3 the change in item_strfunc::Item_func_concat() has to be mirroed
in Item_func_concat_oracle() to avoid future valgrind warnings.

This is a regression caused by
commit 73af8af0
(MDEV-15325 Incomplete validation of missing tablespace during recovery).

If the recv_sys->addr_hash hash table ran out of memory, we would
have to do crash recovery in multiple passes. If some tablespaces were
missing, after the MDEV-15325 fix we would rescan the remaining redo log.
But, we could incorrectly reset the "rescan" flag. Because of this, we
would fail to apply some of the oldest redo log records to the data files.
(The recv_sys->addr_hash would only contain records from the latest
redo log scan batch.)

Fix:

After checking for missing tablespaces, reset the flag rescan=true,
so that all redo log records will be re-read and applied.

pthread_detach_this_thread() was intended to be defined to something
meaningful only on some ancient unixes, which don't have
pthread_attr_setdetachstate() defined. Otherwise, on normal unixes,
threads are created detached in the first place.

This was broken in 0f01bf26 so that
we started calling pthread_detach() for already detached threads.
Intention was to detach aria checkpoint thread.

However in 87007dc2 aria service threads
were made joinable with appropriate handling, which makes breaking
revision unneccessary.

Revert remnants of 0f01bf26, so that
pthread_detach_this_thread() is meaningful only on some ancient unixes
again.

btr_cur_instant_root_init(): Check the "infimum" and "supremum"
record strings already here, and not later in btr_cur_instant_root_init().
In this way, we can properly reject files from later versions where
instant ALTER TABLE could support further operations that change the
format of InnoDB clustered indexes.

SLES11 can't build currently latest Galera library version.