Fix exit condition for the log copying thread.

(https://github.com/facebook/rocksdb/issues/4344)
Also, disable /permissive- flag if set, it breaks rocksdb compilation
in 10.3 on older versions of Windows 8.1 SDK.

It uses --slave-use-idempotent-for-recovery which is not available in MariaDB.

Remove the mismatch betwen list of man pages in CMakeLists.txt and
actual files.

Direct IO doesnt work on all filesystems, e.g. it doesnt work on the
disk of kvm-bintar-trusty-amd64.

This regression was introduced in MDEV-16515.
We would fail to drop a temporary table on client disconnect,
because trx_is_interrupted() would hold. To add insult to
injury, in MariaDB 10.1, InnoDB temporary tables are actually
persistent, so the garbage temporary tables will never be dropped.

row_drop_table_for_mysql(): If several iterations of
buf_LRU_drop_page_hash_for_tablespace() are needed,
do not interrupt dropping a temporary table even after
the transaction was marked as killed.

Server shutdown will still terminate the loop, and also DROP TABLE
of persistent tables will keep checking if the execution was aborted.

This reverts commit 75dfd4ac.

It uses a feature that's not available in MariaDB

It uses a feature that's not available in MariaDB

Plugin version name fixed.

Let '\\' and '/' symbols to be part of a group name.

           Field_iterator_table_ref::set_field_iterator

Several functions that processed different prepare statements missed
the DT_INIT flag in last parameter of the open_normal_and_derived_tables()
calls. It made context analysis of derived tables dependent on the order in
which the derived tables were processed by mysql_handle_derived(). This
order was induced by the order of SELECTs in all_select_list.
In 10.4 the order of SELECTs in all_select_list became different and lack
of the DT_INIT flags in some open_normal_and_derived_tables() call became
critical as some derived tables were not identified as such.

Merged https://github.com/MariaDB/server/pull/617 authored by
Colin Mollenhour.

Move up-to this revision in the upstream:

  commit de1e8c7bfe7c875ea284b55040e8f3cd3a56fcc2
  Author: Abhinav Sharma <abhinavsharma@fb.com>
  Date:   Thu Aug 23 14:34:39 2018 -0700

      Log updates to semi-sync whitelist in the error log

      Summary:
      Plugin variable changes are not logged in the error log even when
      log_global_var_changes is enabled. Logging updates to whitelist will help in
      debugging.

      Reviewed By: guokeno0

      Differential Revision: D9483807

      fbshipit-source-id: e111cda773d

MDEV-14851: galera_recovery to read correct configuration file sections

commit de1e8c7bfe7c875ea284b55040e8f3cd3a56fcc2
Author: Abhinav Sharma <abhinavsharma@fb.com>
Date:   Thu Aug 23 14:34:39 2018 -0700

    Log updates to semi-sync whitelist in the error log

    Summary:
    Plugin variable changes are not logged in the error log even when
    log_global_var_changes is enabled. Logging updates to whitelist will help in
    debugging.

    Reviewed By: guokeno0

    Differential Revision: D9483807

    fbshipit-source-id: e111cda773d

Problem was that a parallel open of a table, overwrote info->state that
was in used by repair.

Fixed by changing _ma_tmp_disable_logging_for_table() to use
a new state buffer state.no_logging to store the temporary state.

Other things:
- Use original number of rows when retrying repair to get rid of a
  potential warning "Number of rows changed from X to Y"
- Changed maria_commit() to make it easier to merge with 10.4
- If table is not locked (like with show commands), use the global
  number of rows as the local number may not be up to date.
  (Minor not critical fix)
- Added some missing DBUG_RETURN

The bug appears because of the Item_func_in::build_clone() method.
The 'array' field for the Item_func_in item that can be pushed into
the materialized view/derived table was built in the wrong way.
It becomes lame after the pushdown of the condition into the first
SELECT that defines that view/derived table. The server crashes in
the pushdown into the next SELECT while trying to use already lame
'array' field.

To fix it Item_func_in::build_clone() was changed.

Currently RocksDB engine doesn't update AUTO_INCREMENT in the UPDATE statement.
For example,

CREATE TABLE t1 (pk INT AUTO_INCREMENT, a INT, PRIMARY KEY(pk)) ENGINE=RocksDB;
INSERT INTO t1 (a) VALUES (1);
UPDATE t1 SET pk = 3; ==> AUTO_INCREMENT should be updated to 4.

Without this fix, it hits the Assertion `dd_val >= last_val' failed in
myrocks::ha_rocksdb::load_auto_incr_value_from_index.

(cherry picked from commit f7154242)

introduced in the patch fo MDEV-16934.

Merge the 10.2 version, which was created by Vasil Dimov.