- Move testing of my_writer to inline functions to avoid calls
- Made more functions inline. Especially thd->thread_started()
  is now very optimized!
- Moved Opt_trace_stmt classe to opt_trace_context.h to get critical
  functions inline

- Added unlikely() to optimize for not having optimizer trace enabled
- Made THD::trace_started() inline
- Added 'if (trace_enabled())' around some potentially expensive code
  (not many found)
- Added ASSERT's to ensure we don't call expensive optimizer trace calls
  if optimizer trace is not enabled
- Added length to Json_writer functions to speed up buffer writes
  when optimizer trace is enabled.
- Changed LEX_CSTRING argument handling to not send full struct to writer
  function on_add_str() functions now trusts length arguments

ha_partition: Remove redundant 'virtual' keywords and add
missing 'override'.

FIXME: handler::table_type() is not declared virtual, yet ha_partition
and ha_sequence are seemingly trying to override it.

- Flag ALTER_STORED_COLUMN_TYPE set while doing varchar extension
for partition table. Basically all partition supports
can_be_converted_by_engine() then it should be set to
ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE.

Main select should be pushed first in case of SET STATEMENT.

Part#2: cleanup:

In the part 1 of the fix, DS-MRR implementation would peek into
the JOIN_TAB to get the rowid filter from

  table->reginfo.join_tab->rowid_filter

This doesn't look good from code isolation standpoint (why should a
storage engine assume it is used through a JOIN_TAB?).

Fixed this by storing the 'un-pushed' rowid_filter in the DsMrr_impl
structure. The filter survives across multi_range_read_init() calls.

It is discarded when somebody calls index_end() or rnd_end() and cleans
up the DsMrr_impl.

The two functions have different signature.
Use "using ..." to prevent shadowing

This patch fixes the following defects/bugs.
1. If BKA[H] algorithm was used to join a table for which the optimizer
had decided to employ a rowid filter the filter actually was not built.
2. The patch for the bug MDEV-21356 that added the code canceling pushing
rowid filter into an engine for the table joined with employment of
BKA[H] and MRR was not quite correct for Innodb engine because this
cancellation was done after InnoDB code had already bound the the pushed
filter to internal InnoDB structures.

Do not rebuild index when it's key part converted from utf8mb3 to utf8mb4
but key part stays the same.

dict_index_add_to_cache(): assert that prefix_len is divided by mbmaxlen

ha_innobase::compare_key_parts(): compare key part lenght in symbols instead
of bytes.

Engine specific code moved to engine.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

Add more tests and move SST restore to correct place.

Remove sleeps and unnecessary waits.

The log file is opened as root since commit bb7a70c9, so there is no need
to chown it.

Test changes only.

Add wait conditions.

MDEV-21421 : Galera test sporadic failure on galera.galera_as_slave_gtid_myisam: Result length mismatch

In Galera 4 nodes 1 and 2 are galera nodes and node_3 should be
non galera.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

Partitioning storage now supports MRR but doesn't support Index Condition
Pushdown (aka ICP). This causes counter-intuitive query plans for queries
that use BKA and conditions that depend on index fields:
- If the condition refers to other tables, BKA's variant of ICP is used
   to handle it.
- If the condition depends on this table only, the optimizer will try to
  use regular ICP for it, which will fail because the storage engine
  doesn't support ICP.

Make the optimizer be smarter in the second case: if we were not able to
use regular ICP, use BKA's variant of ICP..

No longer used.

MDEV-21669 InnoDB: Table ... contains <n> indexes inside InnoDB, which is different from the number of indexes <n> defined in the MariaDB

compare_keys_but_name(): do not use KEY_PART_INFO::field for
Field::is_equal(). Following the logic of that code we need to
compare fields of a table. But KEY_PART_INFO::field sometimes
(when key part is shorter than table field) is a different field.
In that case Field::is_equal() returns incorrect result and
problems occur.

KEY_PART_INFO::field may become some strange field in
open_frm_error open_table_from_share(). I think this is an
incorrect logic, some tecnhical debt. I'm not fixing it right now,
because I don't have time. But I'm making Field::field_length
a const class member. Then, the only fishy code which changed that
field requires now a const_cast<>. I'm bringing attention to that
code with it. This change should not affect logic of the
program in any way.

MDEV-20867 - Perform careful review of "Server crashes with BACKUP STAGE and FLUSH TABLE table_name"

Reverted original patch (c2e0a0b1).

For consistency with "LOCK TABLE <table_name> READ" and "FLUSH TABLES
WITH READ LOCK", which are forbidden under "BACKUP STAGE", forbid "FLUSH
TABLE <table_name> FOR EXPORT" and "FLUSH TABLE <table_name> WITH READ
LOCK" as well.

It'd allow consistent fixes for problems like MDEV-18643.

Context involves semicolon batching, and the error starts 10.2
No reproducible examples were made yet, but TCP trace suggests
multiple packets that are "squeezed" together (e.g overlong OK packet
that has a trailer which is belongs to another packet)

Remove thd->get_stmt_da()->set_skip_flush() when processing a batch.
skip_flush stems from the COM_MULTI code, which was checked in during
10.2 (and is never used)

The fix is confirmed to work, when evaluated by bug reporter (one of them)

We never reproduced it locally, with multiple tries
thus the root cause analysis is still missing.

Problem seems to be the fact that we did not enforce correct
applier thread numbers after every command that effects them.
Test changes only.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

Problem seems to be the fact that we did not enforce correct
applier thread numbers after every command that effects them.
Test changes only.

* Remove those tests that will not be supported on that release.
* Make sure that correct tests are disabled and have MDEVs
* Sort test names

This should not be merged upwards.

The symbol SRV_MASTER_PURGE_INTERVAL became unused in
mysql/mysql-server@42f36919584e82c621dbec1e69fd05ab023c54c6
when separate purge threads were introduced in MySQL 5.6.5.

Do not materialize a semi-join nest if it contains a materialized derived
table /view that potentially can be subject to the split optimization.
Splitting of materialization of such nest would help, but currently there
is no code to support this technique.