MariaDB stopped writing the record MLOG_UNDO_ERASE_END
in commit 0fd3def2 (10.3.3).
Merge trx_undo_erase_page_end() with its callers.

trx_undo_page_init(): Write lower-level redo log records by
invoking mtr_t::write().

page_zip_compress_write_log_no_data(): Remove.
We no longer write the MLOG_ZIP_PAGE_COMPRESS_NO_DATA record.
Instead, we will write MLOG_ZIP_PAGE_COMPRESS records.

No longer emit the redo log records
MLOG_LIST_END_COPY_CREATED, MLOG_COMP_LIST_END_COPY_CREATED.

size_t compared to int

Remove deprecated system variable multi_range_count. It was ignored from 5.3.

Variable is marked as deprecated since 10.1.6. Update tests to not make
use of it.

Remove the option from mysqld --help text.

thread_concurrency was ignored since 5.5. Remove it.

It was deprecated in 5.5 but it never issued a deprecation warning.
Make it issue a warning in 10.5.1.

REMOVED OPTIONS / SYSTEM VARIABLES
  * mysqld removed options will not stop the server from starting. They
    will be silently accepted, as if --loose flag is set. Removed options
    prefixes will not interfere with existing options prefixes. They are
    consumed last.
  * mysqld removed options will not show in --help.
  * mysqld system variables will be removed according to the deprecation
    & removal timeline and not function within the client interface once
    removed.

DEPRECTATED OPTIONS / SYSTEM VARIABLES
  * mysqld deprecated options will issue a warning to the user.
  * mysqld deprecated options will still be visible in --help.
  * mysqld system variables will be removed in the next GA version that is
    past EOL of the version that deprecated the variable.
  * deprecated options / variables will not be used anywhere in the server
    code the moment they are deprecated. At most, they will act as aliases.

The advantage of this policy is that it ensures upgrades will always
allow the user to start the server, even when upgrading from a very old
version. It is still possible for user applications to break when
upgrading, as system variables set via the client interface will return
errors. However, this will happen after a long time, with lots of
warnings between versions. The expected timeline is ~ 5 years until a
deprecated variable dissapears from the server.

Remove usage of deprecated variable storage_engine. It was deprecated in 5.5 but
it never issued a deprecation warning. Make it issue a warning in 10.5.1.

Replaced with default_storage_engine.

For compatibility with diagnostic software, let us
return a dummy buffer pool identifier 0 and restore
the columns that were initially deleted in
commit 1a6f708e:

	information_schema.innodb_buffer_page.pool_id
	information_schema.innodb_buffer_page_lru.pool_id
	information_schema.innodb_buffer_pool_stats.pool_id
	information_schema.innodb_cmpmem.buffer_pool_instance
	information_schema.innodb_cmpmem_reset.buffer_pool_instance

Thanks to Vladislav Vaintroub for pointing this out.

Allocation should use ALIGN_SIZE when we need to make sure that we
have atleast enough space to store one record in MERGEBUFF2 buffers

Our benchmarking efforts indicate that the reasons for splitting the
buf_pool in commit c18084f7
have mostly gone away, possibly as a result of
mysql/mysql-server@ce6109ebfdedfdf185e391a0c97dc6d33867ed78
or similar work.

Only in one write-heavy benchmark where the working set size is
ten times the buffer pool size, the buf_pool->mutex would be
less contended with 4 buffer pool instances than with 1 instance,
in buf_page_io_complete(). That contention could be alleviated
further by making more use of std::atomic and by splitting
buf_pool_t::mutex further (MDEV-15053).

We will deprecate and ignore the following parameters:

	innodb_buffer_pool_instances
	innodb_page_cleaners

There will be only one buffer pool and one page cleaner task.

In a number of INFORMATION_SCHEMA views, columns that indicated
the buffer pool instance will be removed:

	information_schema.innodb_buffer_page.pool_id
	information_schema.innodb_buffer_page_lru.pool_id
	information_schema.innodb_buffer_pool_stats.pool_id
	information_schema.innodb_cmpmem.buffer_pool_instance
	information_schema.innodb_cmpmem_reset.buffer_pool_instance

During native table rebuild or index creation, InnoDB used to skip
redo logging and write MLOG_INDEX_LOAD records to inform crash recovery
and Mariabackup of the gaps in redo log. This is fragile and prohibits
some optimizations, such as skipping the doublewrite buffer for
newly (re)initialized pages (MDEV-19738).

row_merge_write_redo(): Remove. We do not write MLOG_INDEX_LOAD
records any more. Instead, we write full redo log.

FlushObserver: Remove.

fseg_free_page_func(): Remove the parameter log. Redo logging
cannot be disabled.

fil_space_t::redo_skipped_count: Remove.

We cannot remove buf_block_t::skip_flush_check, because PageBulk
will temporarily generate invalid B-tree pages in the buffer pool.

Let us define page_id_t as a thin wrapper of uint64_t so that
the comparison operators can be simplified. This is a follow-up
to the original commit 14be8143.

The comparison operator for recv_sys.pages.emplace() turned out to be
a busy spot in a recovery benchmark. That data structure was introduced
in MDEV-19586 in commit 177a571e.

The linear scan of recv_sys_t::blocks() in recv_sys_t::free()
turns out to dominate the execution time in crash recovery.
Let us scan the much shorter buf_pool->chunks lists instead.

MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage engine of the effected table

Introduced a new wsrep_strict_ddl configuration variable in which
Galera checks storage engine of the effected table. If table is not
InnoDB (only storage engine currently fully supporting Galera
replication) DDL-statement will return error code:

ER_GALERA_REPLICATION_NOT_SUPPORTED
       eng "DDL-statement is forbidden as table storage engine does not support Galera replication"

However, when wsrep_replicate_myisam=ON we allow DDL-statements to
MyISAM tables. If effected table is allowed storage engine Galera
will run normal TOI.

This new setting should be for now set globally on all
nodes in a cluster. When this setting is set following DDL-clauses
accessing tables not supporting Galera replication are refused:

* CREATE TABLE (e.g. CREATE TABLE t1(a int) engine=Aria
* ALTER TABLE
* TRUNCATE TABLE
* CREATE VIEW
* CREATE TRIGGER
* CREATE INDEX
* DROP INDEX
* RENAME TABLE
* DROP TABLE

Statements on PROCEDURE, EVENT, FUNCTION are allowed as effected
tables are known only at execution. Furthermore, USER, ROLE, SERVER,
DATABASE statements are also allowed as they do not really have
effected table.

ANding of the range built from inferred NOT NULL conditions and the range
built from other conditions used in WHERE/ON clauses may produce an
IMPOSSIBLE range. The code of MDEV-15777 did not take into account this
possibility.

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.

Rewriting GRANT/REVOKE grammar to use more bison stack and use Sql_cmd_ style

1. Removing a few members from LEX:
   - uint grant, grant_to_col, which_columns
   - List<LEX_COLUMN> columns
   - bool all_privileges
2. Adding classes Grand_object_name, Lex_grant_object_name
3. Adding classes Grand_privilege, Lex_grand_privilege
4. Adding struct Lex_column_list_privilege_st, class Lex_column_list_privilege
5. Rewriting the GRANT/REVOKE grammar to use new classes and pass them through
   bison stack (rather than directly access LEX members)
6. Adding classes Sql_cmd_grant* and Sql_cmd_revoke*,
   changing GRANT/REVOKE to use LEX::m_sql_cmd.
7. Adding the "sp_handler" grammar rule and removing some duplicate grammar
   for GRANT/REVOKE for different kinds of SP objects.
8. Adding a new rule comma_separated_ident_list, reusing it in:
   - with_column_list
   - colum_list_privilege

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