it contradicted the manual and was inconsistent

Use OpenSSL 1.1 when applicable.
Create compatibility macros for OpenSSL 1.0- and YaSSL.

mariadb-client-core-10.2, mariadb-client-10.2, and
mariadb-server-core-10.2 should not depend on libmariadb3 - they
do not have any binaries dynamically linked with libmariadb3.so

The symlink

/usr/lib/libmysqlclient.so -> /usr/lib/libmysqlclient.so.18

was invalid, because the library was not in /usr/lib.
The correct symlink is

/usr/lib/x86_64-linux-gnu/libmysqlclient.so -> /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18

put libmariadbclient18 symlinks into libmariadbclient18.deb package,
not into libmariadb3.deb, because installing/reinstalling
libmariadbclient18.deb must recreate these symlinks.

post-fix for 04b288ae

Ported fix from mysql-wsrep-bugs with some refactoring.

Test case is MW-402 where MariaDB needs record as there is
extra connection <con_name> lines.

Optimizing cascade node list traversal, which could turn out as
performance bottleneck
Even this current cascade node check could be skipped, but a dedicated
mtr test is needed to confirm that

Use wsrep_must_process_fk function to check if foreign key
constraint needs to be processed in case of Galera is enabled.

Optimizing cascade node list traversal, which could turn out as
performance bottleneck
Even this current cascade node check could be skipped, but a dedicated
mtr test is needed to confirm that

* created tests focusing in multi-master conflicts during cascading foreign key
  processing
* in row0upd.cc, calling wsrep_row_ups_check_foreign_constraints only when
  running in cluster
* in row0ins.cc fixed regression from MW-369, which caused crash with MW-402.test

The purpose of the test is to ensure that redo log apply will
extend data files before applying page-level redo log records.
The test intermittently failed, because the doublewrite buffer
would sometimes contain data for the pages that the test
truncated. When the test truncates data files, it must also remove
the doublewrite buffer entries, because under normal operation, the
doublewrite buffer would only be written to if the data file already
has been extended.

MySQL 5.7 introduced some optimizations to avoid file I/O during
ALGORITHM=INPLACE operations. While both innodb-index-online and
innodb-table-online will exercise both the merge sort files and
the online log files in 10.1, in 10.2 they would only exercise the
online log files.

Modify one test case in innodb.innodb-table-online so that
skip_pk_sort will not hold. In this way, this test case will
write and read the merge sort files. The other instrumented tests
in innodb-index-online and innodb-table-online will only write
and read online_log files.

This should also fix the MariaDB 10.2.2 bug
MDEV-13826 CREATE FULLTEXT INDEX on encrypted table fails.

MDEV-12634 FIXME: Modify innodb-index-online, innodb-table-online
so that they will write and read merge sort files. InnoDB 5.7
introduced some optimizations to avoid using the files for small tables.

Many collation test results have been adjusted for MDEV-10191.

Compilation got confused  about 2 wsrep.h headers in include path
Rename backup's wsrep.h to backup_wsrep.h to fixO

Introduce innodb_encrypt_log.combinations and prove that
the encryption and decryption take place during both
online ADD INDEX (WL#5266) and online table-rebuilding ALTER (WL#6625).

Apply the same changes to both InnoDB and XtraDB.

message was written.

The messages are getting lost because they are written with fprintf()
but without fflush(), so abort() would lose buffered text.

Applied fix from 10.2, which makes in_logf() use
sql_print_information(), which in turn does proper flush after each message

MDEV-13807 mariabackup --apply-log-only does generate redo log by performing rollback and possibly other tasks

Skip rollback and other redo-log-generating tasks if
srv_apply_log_only is set.

Instead of assigning the debug variable recv_no_log_write = FALSE,
assign it to srv_apply_log_only, so that any unwanted writes are caught.

The underlying data members are declared public, so there is no
point in hiding these const accessors.

Use dict_index_is_auto_gen_clust() instead.

The problem was introduced by the patch for MDEV-7661,
which (in addition to the fix itself) included an attempt to make
CONVERT/CAST work in the same way with fields
(i.e. return NULL in strict mode if a non-convertable character found).
It appeared to be a bad idea and some users were affected by this
behavior change. Changing CONVERT/CAST not depend on sql_mode
(restoring pre-10.1.4 behavior).

use ut_get_name() for formatting database/table names.

* recorded new result file, original was copied from MariaDB
  which produces syntactically a bit different result
* semantics are same in MariaDB and ours result file

* changed thd_binlog_format to return configured binlog format in wsrep execution,
  regardless of binlogging setting (i.e. with or without binlogging)
* thd_binlog_format is used in innobase::write_row(), and would return confusing
  result there when log_bin==OFF

* ported the partition.test from MariaDB 10.3 code tree
* fix to TOI replicate ALTER TABLE EXCHANGE PARTITION statement

Import the changes to innodb.innodb-index innodb.innodb-index-debug

Note: As noted in MDEV-13613, due to the behaviour change in MDEV-11114,
DROP COLUMN will not imply DROP/ADD PRIMARY/UNIQUE KEY, like it does
in MySQL. The tests have been adjusted accordingly.