If we have a 2+ node cluster which is replicating from an async master
and the binlog_format is set to STATEMENT and multi-row inserts are executed
on a table with an auto_increment column such that values are automatically
generated by MySQL, then the server node generates wrong auto_increment
values, which are different from what was generated on the async master.

In the title of the MDEV-9519 it was proposed to ban start slave on a Galera
if master binlog_format = statement and wsrep_auto_increment_control = 1,
but the problem can be solved without such a restriction.

The causes and fixes:

1. We need to improve processing of changing the auto-increment values
after changing the cluster size.

2. If wsrep auto_increment_control switched on during operation of
the node, then we should immediately update the auto_increment_increment
and auto_increment_offset global variables, without waiting of the next
invocation of the wsrep_view_handler_cb() callback. In the current version
these variables retain its initial values if wsrep_auto_increment_control
is switched on during operation of the node, which leads to inconsistent
results on the different nodes in some scenarios.

3. If wsrep auto_increment_control switched off during operation of the node,
then we must return the original values of the auto_increment_increment and
auto_increment_offset global variables, as the user has set. To make this
possible, we need to add a "shadow copies" of these variables (which stores
the latest values set by the user).

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

           with UNION ALL after INTERSECT

EXPLAIN EXTENDED erroneously showed UNION instead of UNION ALL in
the warning if UNION ALL followed INTERSECT or EXCEPT operations.
The bug was in the function st_select_lex_unit::print() that printed
the text of the query used in the warning.

This is done in order to help debugging buildbot failures.

but even if this script called as /bin/mysql_install_db
it is still standard install and scripts are in /usr/share/
(but not in the /share/)
2. fix of bindir path

trx_rseg_t::is_persistent(): Correct a bogus debug assertion.

log_group_read_log_seg(): Always return false when returning
before reading end_lsn.

xtrabackup_copy_logfile(): On error, indicate whether
a corrupt log record was encountered.

Only xtrabackup_copy_logfile() in Mariabackup cared about the
return value of the function. InnoDB crash recovery was not
affected by this bug.

By pure chance the macro worked in the cases it was used, but
better to get this fixed!

dict_create_foreign_constraints_low(): Clean up the way in
which the error messages are initialized, and ensure that
the table name is always initialized.

Fix incremental prepare to copy #rocksdb subdirectory from the
incremental dir.

If --debug=d,innodb_skip_monitors is specified, skip the creation
of srv_error_monitor_thread and srv_monitor_thread. In this way,
interactive debugging sessions will not be interfered by messages
about a mutex or rw_lock being held for a long time.

Closes #1192

In tests that directly write InnoDB data file pages,
compute the innodb_checksum_algorithm=crc32 checksums,
instead of writing the 0xdeadbeef value used by
innodb_checksum_algorithm=none. In this way, these tests
will not cause failures when executing
./mtr --mysqld=--loose-innodb-checksum-algorithm=strict_crc32

The variable is obsolete.
In mariabackup --backup, encryption plugin loading code sets the value
this parameter to the same as in server.

In mariabackup --prepare, no new redo  log is generated,
and xtrabackup_logfile is removed after it anyway.

Remove 'register' quantifer from args too.

This was added in 29fa7252 (in 2000) and nothing defines
NEW_HASH_FUNCTION. A low collision is the wrong tradeoff,
it should be focused on throughput.

d405bee0 shows the existing function
is pretty cpu intensive and needs to be improved as well.

- CREATE TABLE ... SELECT drops constraints for columns that
  are both in the create and select part.
  - Fixed by copying the constraint in
    Column_definiton::redefine_stage1_common()
- If one has both a default expression and check constraint for a
  column, one can get the error "Expression for field `a` is refering
  to uninitialized field `a`.
  - Fixed by ignoring default expressions for current column when checking
    for CHECK constraint

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

Even the EINTR case its maybe closed. Take the prudent approach here
an risk leaking one file descriptor rather than closing one that is
nolonger ours.

No need to call list.empty(): first one is called by List constructor,
second one doesn't make sense as the object is destroyed immediately
afterwards.

Also always empty list rather than only if there is no error.

cmake/submodules: notify user about gitconfig for automatic update

Co-Authored-By: grooverdan <daniel@linux.ibm.com>