In a general case the conditions with outer fields cannot
be pushed into materialized views / derived tables.
However if the outer field in the condition refers to a
single row table then the condition may be pushable.
In this case a special care should be taken for outer
fields when pushing the condition into a materialized view /
derived table.

        The rest of mysql/json functions implemented.
        CAST AS JSON implemented.

- added missing backslash
- removed duplicate definition of UT_LOW_PRIORITY_CPU/UT_RESUME_PRIORITY_CPU
- removed duplicate UT_RESUME_PRIORITY_CPU call

If a recursive CTE referred to a materialized view/derived table then
the query that used this CTE returned a bogus error message.

If mysqld crashed during the test suite run and gdb is available,
a stack trace will be printed automatically.

Code calling mtflush threads to exit was too late.

When we enter here wait_lock could be already gone i.e. NULL, that
should be allowed.

This is not a fix, this is instrumentation to find the bug.

During total-order replication, Query_log_event's checksum_alg
should be explicitly set to the current binlog_checksum as it
is not set for DML queries.
Note: wsrep_replicate_myisam enables replication of DMLs on
MyISAM tables using TOI.

See https://github.com/MariaDB/server/pull/235
I submit this code under the BSD-new license.

thd->variables.option_bits need to be restored after
plugin_thdvar_init() during post initialization of
wsrep threads.

Postfix: The pre-initialization of wsrep threads is not needed
for mysqldump sst method.

When a BF thread attempts to abort a victim thread's transaction,
the victim thread is not locked and thus its not safe to rely on
its data structures like htons registered for the trx.

So, instead of getting the registered htons from victim, innodb's
hton can be looked up directly from installed_htons[] and used to
abort the transaction. (Same technique is used in older versions)

Perform a post initialization of plugin-related variables
of wsrep threads after their global counterparts have been
initialized.

The crash is caused due to a race condition where wsrep
startup threads invoke ha_maria::implicit_commit() method
while maria_hton is partially initialized. The fix is to
skip this method if plugins are uninitialized.

MDEV-9820 Added server variable compression_default, which if 1/ON sets compres…

Do not include the suite into the default list until the tests are stable

MDEV-11195: Correct enablement of NUMA in innodb/xtradb

Added server variable compression_default, which if 1/ON sets compression on for all new InnoDB/XtraDB tables by default by setting PAGE_COMPRESSED=1

The .rdiff applied ok locally with my copy of patch, but failed with
"misordered hunks" on a test host. Maybe that host has a more strict
version of `patch`.

With "WL#6047 - Do not allocate trx id for read-only transactions"
m_prebuilt->trx->id is always 0 for read-only transactions. This makes
it useless as an index for fuzzy counters.

Use server thread id instead similarly to MySQL.

Conflicts:
	sql/share/errmsg-utf8.txt

BINLOG statement output by mysqlbinlog actually has the base64 of the
non-compressed event. So remove my previous incorrect review change,
which allowed compressed event types for BINLOG statement.

Also add a couple test cases for this, running mysqlbinlog | mysql.

            for InnoDB tables"

Don't use thr_lock.c locks for InnoDB tables. Below is list of changes that
were needed to implement this:
- HANDLER OPEN acquireis MDL_SHARED_READ instead of MDL_SHARED
- HANDLER READ calls external_lock() even if SE is not going to be locked by
  THR_LOCK
- InnoDB lock wait timeouts are now honored which are much shorter by default
  than server lock wait timeouts (1 year vs 50 seconds)
- with @@autocommit= 1 LOCK TABLES disables autocommit implicitely, though
  user still sees @@autocommt= 1
- the above starts implicit transaction
- transactions started by LOCK TABLES are now rolled back on disconnect
  (previously everything was committed due to autocommit)
- transactions started by LOCK TABLES are now rolled back by ROLLBACK
  (previously everything was committed due to autocommit)
- it is now impossible to change BINLOG_FORMAT under LOCK TABLES (at least
  to statement) due to running transaction
- LOCK TABLES WRITE is additionally handled by MDL
- ...in contrast LOCK TABLES READ protection against DML is pure InnoDB
- combining transactional and non-transactional tables under LOCK TABLES
  may cause rolled back changes in transactional table and "committed"
  changes in non-transactional table
- user may disable innodb_table_locks, which will cause LOCK TABLES to be
  noop basically

Removed tests for BUG#45143 and BUG#55930 which cover InnoDB + THR_LOCK. To
operate properly these tests require code flow to go through THR_LOCK debug
sync points, which is not the case after this patch. These tests are removed
by WL#6671 as well. An alternative is to port them to different storage engine.

.result file update for --embedded test run.

(+ default values)

Issue:
======
Currently the approach we take to find the chunk corresponding to a given
pointer uses srv_buf_pool_chunk_unit based on the assumption that
srv_buf_pool_chunk_unit is the total size of all pages in a buffer pool
chunk. We first step back by srv_buf_pool_chunk_unit bytes and use
std::map::upper_bound() to find the first chunk in the map whose key >= the
resulting pointer.

However, the real size of a chunk (and thus, the total size of its pages)
may differ from the value configured with innodb_buffer_pool_chunk_size
due to rounding up to the OS page size. So, in some cases the above logic
gives us the wrong chunk.

Fix:
====
We find out the chunk corresponding to the give pointer without using
srv_buf_pool_chunk_unit. This is done by using std::map::upper_bound()
to find the next chunk in the map which appears right after the pointer and
decrementing the iterator, which would give us the chunk the pointer
belongs to.

Contribution by Alexey Kopytov.

RB: 13347
Reviewed-by: Debarun Banerjee <debarun.banerjee@oracle.com>