TABLE_SHARE::init_from_binary_frm_image has a rule: if an index
has a partially-covered column (like in "KEY(col(N))" ), then dont
provide "Extended Keys" feature for this index.

The problem was that due to coding error Extended Keys feature was
disabled for *ALL* subsequent indexes. Fixed the error.

The problem was introduced by 1859caf6:
  MDEV-10175: range optimizer calls records_in_range() for full extended keys

  Make the range optimizer not call records_in_range() when it would
  not give any benefit.

that patch used an incorrect way to check for full extended key. Now fixing
the check.

Add ProtectSystem=full, NoNewPrivileges=true, PrivateDevices=true, and ProtectHome=true to the systemd units.

MDEV-10318 : Fix crash in embedded, in case prepared statement has parameter placeholders, but does not bind parameters

On Solaris mktime() adds one extra day to tm_mday field and returns appropriate
value for dates 1600-01-01 and earlier. That is 1600-01-01 becomes 1600-01-02.

Solaris mktime manual excerpts:
  ...
  The tm_year member must be for year 1901 or later.  Calendar
  times  before  20:45:52  UTC,  December  13,  1901  or after
  03:14:07 UTC,  January 19, 2038 cannot be represented. Port-
  able  applications  should  not  try  to create dates before
  00:00:00 UTC, January 1, 1970 or after 00:00:00 UTC, January
  1, 2038.
  ...
  The  mktime() function assumes Gregorian dates. Times before
  the  adoption  of the Gregorian calendar will not match his-
  torial records.
  ...

According to manual Mroonga only supports dates and datetimes after 1900:
https://mariadb.com/kb/en/mariadb/about-mroonga/

Technically these tests cover unsupported values and should fail on all
platforms. Disable tests until the problem is fixed upstream.

Avoid recursive LOCK_system_variables_hash acquisition in
intern_sys_var_ptr() by pre-syncing dynamic session variables.

The crash was caused by this problem:
get_best_group_min_max() tries to construct query plans for keys that
are not processed by the range optimizer. This wasn't a problem as long
as SEL_TREE::keys was an array of MAX_KEY elements.
However, now it is a Mem_root_array and only has elements for the used
keys, and get_best_group_min_max attempts to address beyond the end of
the array.

The obvious way to fix the crash was to port (and improve) a part of
96fcfcbd7b5120e8f64fd45985001eca8d36fbfb from mysql-5.7. This makes
get_best_group_min_max not to consider indexes that Mem_root_arrays
have no element for.

After that, I got non-sensical query plans (see MDEV-10325 for details).
Fixed that by making get_best_group_min_max to check if the index is in
table->keys_in_use_for_group_by bitmap.

(MDEV-9407, MDEV-9408) from 10.1

Needed to fix MDEV-10317 easier.

"thd" is available through the "table" argument, as table->in_use.

Backporting (partially) from 10.2.

Cross Compile HAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE change to compile check

HAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE only needed a compile check
rather than a RUN check so after changing to a compile check there
is one less variable to manually set while cross compiling.

.. file '/var/log/mysql/mariadb-bin.000001' not found in binlog
index, needed for recovery. Aborting.

In Galera cluster, while preparing for rsync/xtrabackup based
SST, the donor node takes an FTWRL followed by (REFRESH_ENGINE_LOG
in rsync based state transfer and) REFRESH_BINARY_LOG. The latter
rotates the binary log and logs Binlog_checkpoint_log_event
corresponding to the penultimate binary log file into the new file.
The checkpoint event for the current file is later logged
synchronously by binlog_background_thread.

Now, since in rsync/xtrabackup based snapshot state transfer methods,
only the last binary log file is transferred to the joiner node; the
file could get transferred even before the checkpoint event for the
same file gets written to it. As a result, the joiner node would fail
to start complaining about the missing binlog file needed for recovery.

In order to fix this, a mechanism has been put in place to make
REFRESH_BINARY_LOG operation wait for Binlog_checkpoint_log_event
to be logged for the current binary log file if the node is part of
a Galera cluster. As further safety, during rsync based state transfer
the donor node now acquires and owns LOCK_log for the duration of file
transfer during SST.

SSL: do not require client certificate to exist,
if GRANT didn't require that

ut_a(state == BUF_BLOCK_NOT_USED
     || state == BUF_BLOCK_REMOVE_HASH);
is hit.

fix the *other* fill_record() too, arrgh!

set CPACK_COMPONENTS_ALL both on the current and parent scope

s/unixODBC/unixodbc/

Item_cache::is_null() erroneously returned null_value in a
non-cached state. Now Item_cache::is_null() uses has_value(),
which caches the value if not cached yet, similar to what other value methods do
(e.g. val_int, val_real, etc).

Using IP address in donor's socat with TLS/SSL and certificate
which doesn't contain IP address in CN or SubjectAltName causes
transfer to fail with message:

socat[5799] E certificate is valid but its commonName does not
match hostname.

This patch tries to reverse resolve IP address to hostname and
use it for transfer. If reverse resolution fails, IP address is
still used as fall-back, so proper A/AAAA and PTR records are
important, but not mandatory.

Certain certificates cannot contain IP addresses, e.g. FreeIPA's
Dogtag doesn't allow it, so in my case I would need to use self-
signed certificates instead, use verify=0 with socat or don't use
TLS/SSL at all. Issue is mentioned in MDEV-9403.

Since wsrep_sync_wait & wsrep_causal_reads variables are related,
they are always kept in sync whenever one of them changes.
Same is tried on server start, where wsrep_sync_wait get updated
based on wsrep_causal_reads' value. But, since wsrep_causal_reads
is OFF by default, wsrep_sync_wait's value gets modified and loses
its WSREP_SYNC_WAIT_BEFORE_READ bit.

Fixed by syncing wsrep_sync_wait & wsrep_causal_reads values
individually on server start in mysqld_get_one_option() based
on command line arguments used.

Added a new --wsrep-new-cluster option to enable mysqld_multi
script to start mysqld with the same option.

[Patch contributed by Hartmut]

Append mysqld_safe's wsrep-on option to the list of options
used to start mysqld.
[Patch contributed by Hartmut]

In CTAS, handlers get registered under statement transaction
(st_transactions::stmt), while ha_fake_trx_id(), used by CTAS,
looked under standard transaction (st_transactions::all) for
registered handlers, and thus it failed to grab a fake transaction
ID. As a result, with no valid transaction ID, wsrep commit failed
with an error.

ha_fake_trx_id() now looks for handlers registered under 'stmt'
in case 'all' is empty. Also modified the logic to print warning
only once if none of the registered handlers have fake_trx_id.

On wsrep_cluster_address update, node restarts the replication
and attempts to connect to the new address. In this process it
makes a call to wsrep provider's connect API, which could lead
to segfault if wsrep provider is not loaded (wsrep_on=OFF).

Fixed by making sure that it proceeds only if a provider is
loaded.

Update sys_vars.sysvars_wsrep test.

Galera recovery process works in two phases. In the first
phase, mysqld is started as non-daemon with --wsrep-recover
to recover and fetch the last logged global transaction ID.
This ID is then used in second phase as the start position
(--wsrep-start-position=XX) to start mysqld as daemon.

As this process was implemented in mysqld_safe script, the
recovery did not work when server was started using systemd.

Fixed by introducing a shell script (wsrep_recovery.sh) that
mimics the first phase of the recovery process.

--defaults-xxx options must be placed before all other
options in the command line. Also moved MYSQLD_OPTS at
the end so that its options take precedence.