Using a boolean flag for 'there is a RESET MASTER in progress' doesn't
work very well for multiple concurrent RESET MASTER statements.
Changed to a counter.

MDEV-7299 Assertion `m_status == DA_ERROR || m_status == DA_OK' fails on concurrent execution of DDL, queries from I_S, and KILL QUERY

Fix MDL to report an error when a wait was killed, but preserve
the old documented behavior of GET_LOCK() where killing it is not an error.

Also remove race conditions in main.create_or_replace test

revert the code in filesort that conditionally updated 'found_rows',
rely on filesort_limit_arg instead.

MDEV-7186 get_lock() crashes on Windows, main.sp_notembedded and main.trigger_notembedded fail in buildbot

user locks are not affected by lowed_case_table_names

change the test not to use absolute values of Key_blocks_unused.

reset KILL_QUERY when a new query execution is just about to be started

copy the workaround from 5.5

This patch ports the work that facebook has performed
to make innochecksum handle compressed tables.
the basic idea is to use actual innodb-code to perform
checksum verification rather than duplicating in innochecksum.cc.
to make this work, innodb code has been annotated with
lots of #ifndef UNIV_INNOCHECKSUM so that it can be
compiled outside of storage/innobase.

A new testcase is also added that verifies that innochecksum
works on compressed/non-compressed tables.

Merged from commit fabc79d2ea976c4ff5b79bfe913e6bc03ef69d42 
from https://code.google.com/p/google-mysql/

The actual steps to produce this patch are:

    take innochecksum from 5.6.14
    apply changes in innodb from facebook patches needed to make innochecksum compile
    apply changes in innochecksum from facebook patches
    add handcrafted testcase

The referenced facebook patches used are:

    https://github.com/facebook/mysql-5.6/commit/91e25120e75272db4cdbc07d0e45877d9dea5715
    https://github.com/facebook/mysql-5.6/commit/847fe76ea5239b09fa361b023c56e6be76d32046
    https://github.com/facebook/mysql-5.6/commit/1135628a5a9b3412621b93233478f3804bcef51a
    https://github.com/facebook/mysql-5.6/commit/4dbf7c240ce2f08b7d6572d9452c9779ce90641c

mysql-test/suite/maria/insert_select.result:
  Added test case
mysql-test/suite/maria/insert_select.test:
  Added test case
mysys/thr_lock.c:
  Ensure we don't allow concurrent_insert when a read_no_write lock is in use

Stage "Filling schema table" is now properly shown in 'show processlist'


mysys/mf_keycache.c:
  Simple cleanup with more comments
sql/lock.cc:
  Return to original stage after mysql_lock_tables
  Made 'Table lock' as a true stage
sql/sql_show.cc:
  Restore original stage after get_schema_tables_result

- The code that tested if
     WHERE expr=value AND expr=const
  can be rewritten to:
     WHERE const=value AND expr=const
  was incomplete in case of STRING_RESULT.
- Moving the test into a new function, to reduce duplicate code.

FULLTEXT indexes do not permit index first lookups. By calling:
ha_index_first() with a garbage parameter, random data gets overwritten
that causes the table->field array to be corrupted. Subsequently, when
the field array is accessed, a segfault occurs.

By not allowing index statistics for FULLTEXT indexes, the problem is
resolved.

Fixing a wrong assymetric code in Arg_comparator::set_cmp_func().
It existed for a long time, but showed up in 10.0.14 after the fix
for "MDEV-6666 Malformed result for CONCAT(utf8_column, binary_string)".

MDEV-7254 Assigned expression is evaluated twice when updating column TIMESTAMP NOT NULL
The test type_timestamp failed depending on the build machine time zone.
Setting a fixed time zone for the test.

column TIMESTAMP NOT NULL
      
Analysis: Problem was that value->is_null() function is called
even when user had explicitly set the value for timestamp
field. Calling this function had the side effect that
expression was evaluated twice.
      
Fix: (by Sergei Golubchik) check instead value->null_value.

	innodb_bug12400341
	innodb-mdev7046
	innodb_stats_fetch_nonexistent

  
Structure of the table created by the test to archive mysql.slow_log
data didn't match the structure of mysql.slow_log. The failure only 
appeared if the slow_log was not empty, which was very rare. 
  
Updated the structure of the table. 

The problem was a too low timeout for slave reconnect. It was set to 9 seconds
(10 retries with 1 second in-between). This is occasinally too short on some
Buildbot hosts, when the test crashes and restarts the master while the slave
IO thread is running.

Fix by increasing --master-retry-count for this test.

            mysql.service failed to load

Added 'systemctl daemon-reload' command in postin and
postun rpm scripts.

The test case injects a DBUG that will crash the server during replication,
then does a START SLAVE. We need to use --error 0,2006,2013 on the START
SLAVE, so that we will not fail the test if the server has time to crash
before the START SLAVE returns to the client.

Fixes a failure seen in Buildbot.

Test causes OS error printout and we need to supress this
error message on tests. Additionally, test could cause
different error codes on different OSs.

The bug occurs when a transaction does a retry after all transactions have
done mark_start_commit() in a batch of group commit from the master. In this
case, the retrying transaction can unmark_start_commit() after the following
batch has already started running and de-allocated the GCO. Then after retry,
the transaction will re-do mark_start_commit() on a de-allocated GCO, and also
wakeup of later GCOs can be lost.

This was seen "in the wild" by a user, even though it is not known exactly
what circumstances can lead to retry of one transaction after all transactions
in a group have reached the commit phase.

The lifetime around GCO was somewhat clunky anyway. With this patch, a GCO
lives until rpl_parallel_entry::last_committed_sub_id has reached the last
transaction in the GCO. This guarantees that the GCO will still be alive when
a transaction does mark_start_commit(). Also, we now loop over the list of
active GCOs for wakeup, to ensure we do not lose a wakeup even in the
problematic case.

Analysis: For some reason actual thread handle is not
returned on Windows instead lpThreadId was returned and
thread handle was closed after thread create. Later
CloseHandle was called for recv_writer_thread_handle
and psort_info->thread_hdl.

Fix: Return thread handle from os_thread_create()
also on Windows and store these thread handles also
in srv0start.cc so that they can be later closed.

Use include/sync_with_master_gtid.inc instead of --sync_with_master to avoid a
race in the test case.

In parallel replication, the old-style slave position (which is used by
--sync_with_master) is updated out-of-order between parallel threads. This
makes it possible for the position to be updated past DROP TEMPORARY TABLE t2
just before the commit of INSERT INTO t1 SELECT * FROM t2 becomes visible.

In this case, there is a small window where a SELECT just after
--sync_with_master may not see the changes from the INSERT.

The bug was fixed by Serg earlier by including Sphinx 2.2.6, but he forgot to update the test case.

Patch by James Taylor.

scripts/mysql_system_tables.sql:
  Removed DEFAULT from a blob definition as this can cause problems.

Fix a possible race in the test case when restarting the server.

Make sure we have disconnected before waiting for the reconnect
that signals that the server is back up. Otherwise, we may in
rare cases continue the test while the old server is shutting
down, eventually leading to "connection lost" failure.