This is motivated by PS-5221 in
percona/percona-server@2817c561fce9e20a83b13272ac45fd333467715d

The coarser-precision ut_time() will still refer to the
system clock, meaning that bad things can happen if the
real time clock is adjusted backwards.

Valgrind started supporting CRC32 instruction starting with version
3.6.1, released in 2011. Thus remove the fallback to software
implementation in case running under Valgrind.

There is one directly applicable change to InnoDB:
commit 739f5239 in the
5.5 branch will be merged before the next MariaDB releases.

Another potentially applicable change will be tracked
separately as MDEV-20126.

Thus, here we only update the InnoDB version number and do
not change anything else.

This is follow-up to d36c107a

This is a regression due to MDEV-16515 that affects some versions in
the MariaDB 10.1 server series starting with 10.1.35, and possibly
all versions starting with 10.2.17, 10.3.8, and 10.4.0.

The idea of MDEV-16515 is to allow DROP TABLE to be interrupted,
in case it was stuck due to some concurrent activity. We already
made some cases of internal DROP TABLE immune to kill in MDEV-18237,
MDEV-16647, MDEV-17470. We must include the cleanup of
CREATE TABLE...SELECT in the list of such internal DROP TABLE.

ha_innobase::delete_table(): Pass create_failed=true if the current
SQL statement is CREATE, so that the table will be dropped.

row_drop_table_for_mysql(): If create_failed=true, do not allow
the operation to be interrupted.

The results are nondeterministic on MariaDB Server 10.1.

row_merge_read_clustered_index(): make buf always equals to merge_buf[i]

MDEV-11154: Write_on_release_cache(log_event.cc) function will not write "COMMIT", if use "mysqlbinlog ... | mysql ..."

Problem:
=======
Executing command, "mysqlbinlog --read-from-remote-server --host='xx.xx.xx.xx'
--port=3306 --user=xxx --password=xxx --database=mysql --to-last-log
mysql-bin.000001 --start-position=1098699 --stop-never |mysql -uxxx -pxxx", we
found that last data read from remote couldn't commit.

Analysis:
========
The purpose of 'Write_on_release_cache' is that the contents of the Cache will
automatically be written to a dedicated result file on destruction. Flush
operation on the result file is controlled by a flag 'FLUSH_F'. Events which
require force flush upon their destruction will have to enable this
'Write_on_release_cache::FLUSH_F'. At present the 'FLUSH_F' flag is defined as
an enum as shown below.

enum flag
{
  FLUSH_F
};

Since 'FLUSH_F' is the first member without initialization it get the default
value '0'. Because of this the following flush condition never succeeds.

if (m_flags & FLUSH_F)
  fflush(m_file);

At present the file gets flushed only during my_fclose(result_file) operation.
When continuous streaming is enabled through --stop-never option it never gets
flushed and hence events are not replicated.

Fix:
===
Initialize the enum value to non zero value.

Problem:
=======
  Checksum fields can have value as zero. In that case, InnoDB falsely
consider that page should be all zeroes. It leads to wrong detection of page
corruption.

Solution:
========
	Remove the condition that checks if checksum fields are zero then
page should be all zeroes.

that was lost in c5427172

remove zlib/libxml2 workaround in CONNECT

also get rid of

   chown: cannot access ‘/var/lib/mysql’: No such file or directory

before someone reports a bug that
MariaDB server or backup RPM install assumes mysql datadir exists

followup for bee24fe1

MDEV-17588 replicate-do filters cause errors when creating filtered-out tables on master with syntax unsupported on slave

Add only test case for MDEV , because MDEV-19653 already fixed the issue.

MDEV-17963: Assertion `field_pos < field_count' failed in Protocol_text::store, Assertion `field_handlers == 0 || field_pos < field_count'

The problem was that sp_head::MULTI_RESULTS was not set correctly for ANALYZE statement
with SELECT ... INTO variable.
This is a follow up fix for MDEV-7023

This was caused by 7f2cfa8f

Adding tests for MDEV-17857 Assertion `tmp != ((long long) 0x8000000000000000LL)' failed in TIME_from_longlong_datetime_packed upon SELECT with GROUP BY

(they were forgotten in the previous commit)

MDEV-17857 Assertion `tmp != ((long long) 0x8000000000000000LL)' failed in TIME_from_longlong_datetime_packed upon SELECT with GROUP BY

mysqld_safe shouldn't try to mkdir or chown if --dry-run

MDEV-19481 mariadb-10.3.15-linux-systemd-x86_64/bin/mysqld: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' and 'GLIBCXX_3.4.21' not found

don't ignore LIBSYSTEMD_LDFLAGS when trying out systemd

(and put them in LIBSYSTEMD, because MYSQLD_LINK_FLAGS has stuff like
-lmtmalloc and is used only for mysqld, not for, say, explain_filename-t)

LIBSYSTEMD_LDFLAGS come from libsystemd.pc via pkg-config

'syslog' output type disabled on Windows.

MDEV-19660: wsrep_rec_get_foreign_key() is dereferencing a stale pointer to a page that was previously latched

In row_ins_foreign_check_on_constraint(), clustered index record is being passed to wsrep_append_foreign_key() after releasing the latch. If a record has been changed by other thread in the meantime then it could lead to a crash when
wsrep_rec_get_foreign_key () tries to access the record.

row_ins_foreign_check_on_constraint
	Use cascade->pcur->old_rec instead of clust_rec.

row_ins_check_foreign_constraint
	Add missing error printout.

On mips,  ELOOP is 90, instead of 40 or 20.
So we need to replace_regex 90 to 20, too.

Cleanup the nodes before and after test run

Problem:
=======
Executing test with following options will result in test failure.

./mtr rpl.kill_race_condition{,,,,,,,,,,} --repeat=10 --par 12 --mem

Fix:
====
Test simulates applier thread kill scenario while applying a row event.  But it
doesn't wait for applier to catch the error stop.

Added :wait_for_slave_sql_error.inc to catch the error.

Test uses START SLAVE as a final step and doesn't wait for both threads to
start.

Added: start_slave.inc

The test allowed non-deterministic execution thanks to unresetable status
var of Slave_connections.

Fixed with expecting a correct value for Slaves_connected.