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.

Clean the binlog on nodes after test is complete

Since the purpose of event is just to see on second node whether it is
created or not And we are not goint to execute the event also. So instead
of setting GLOBAL event_scheduler=ON and then turning it off,  we can just
disable the warning.

Don't delete the rpl_filter on RESET SLAVE.

Truncate the mysql.slow_log table after test is complete.

cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug

Maintainer mode makes all warnings errors. This patch fix warnings. Mostly about
deprecated `register` keyword.

Too much warnings came from Mroonga and I gave up on it.

- When recovery failed, errors would not be printed on
  new lines.
- Print more information if file lengths are changed
- Added logging of table name for entries INCOMPLETE_LOG and
  REDO_REPAIR_TABLE

MDEV-18461 Aria crash recovery failures

This does not fix the bug reported in the MDEV, but
now we get an error message of the problem instead of
an assert.

This helps when merging code between releases

Check FILE privelege.

Colors possibility auto detected. [ such ] stuff is colored.

Patch by Sergei Golubchik

           in where clause

The classes Item_func_isnottrue and Item_func_isnotfalse inherited the
implementation of the eval_not_null_tables method from the Item_func
class. As a result the not_null_tables_cache was set incorrectly for
the objects of these classes. It led to improper conversion of outer
joins to inner joins when the where clause of the processed query
contained IS NOT TRUE or IS NOT FALSE predicates. The coverted query
in many cases produced a wrong result set.

Plugin fixed to not lock the LOCK_operations when not active.
Server fixed to lock the LOCK_plugin less - do it once per
thread and then only if a plugin was installed/uninstalled.

Explicitly mention every options in .clang-format to protect us from possible
future changes.

Remove separate InnoDB style.

Change style to look more like this script:
for x in $@
do
 indent -kr -bl -bli0 -l79 -i2 -nut -c48 -dj -cp0 $x
 sed -ri -e 's/ = /= /g'\
         -e '/switch.*\)$/{N;s/\n[ ]+/ /}' $x
done

Significant different is that 'switch' and '{' are put on different lines
because it's impossible in clang-format to set formatting rules just for
'switch' statement.

Remove the test, because it easily fails with a result difference.
Analysis by Thirunarayanan Balathandayuthapani:

By default, innodb_encrypt_tables=0.
1) Test case creates 100 tables in innodb_encrypt_1.
2) creates another 100 unencrypted tables (encryption=off) in innodb_encrypt_2
3) creates another 100 encrypted tables (encryption=on) in innodb_encrypt_3
4) enabling innodb_encrypt_tables=1 and checking that only
100 encrypted tables exist. (already we have 100 in dictionary)
5) opening all tables again (no idea why)
6) After that, set innodb_encrypt_tables=0 and wait for 100 tables
to be decrypted (already we have 100 unencrypted tables)
7) dropping all databases

Sporadic failure happens because after step 4, it could encrypt the
normal table too, because innodb_encryption_threads=4.

This test was added in MDEV-9931, which was about InnoDB startup being
slow due to all .ibd files being opened. There have been a number of
later fixes to this problem. Currently the latest one is
commit cad56fba, in which some tests
(in particular the test innodb.alter_kill) could fail if all InnoDB
.ibd files are read during startup. That could make this test redundant.

Let us remove the test, because it is big, slow, unreliable, and
does not seem to reliably catch the problem that all files are being
read on InnoDB startup.