Do not build range filters with detected impossible WHERE.
Anyway conditions cannot be used anymore to extract ranges for filters.

Right argument of Item_in_optimizer can not be cast to Item_in_subselect in invisible mode.

slave_list was used to provide data for SHOW SLAVE HOSTS and
Slaves_connected status variable.

Introduced binlog_dump_thread_count which is exposed via Slaves_connected
(replaces slave_list.records).

Store Slave_info on THD and access it by iterating server_threads
(replaces slave_list).

Added:
THD::slave_info
binlog_dump_thread_count
show_slave_hosts_callback()

Removed:
slave_list
SLAVE_LIST_CHUNK
SLAVE_ERRMSG_SIZE
slave_list_key()
slave_info_free()
init_slave_list()
end_slave_list()
all_slave_list_mutexes
init_all_slave_list_mutexes()
key_LOCK_slave_list
LOCK_slave_list

Moved:
SLAVE_INFO -> Slave_info
register_slave() -> THD::register_slave()
unregister_slave() -> THD::unregister_slave()

Also removed redundant end_slave() from close_connections(): it is called
again soon afterwards by clean_up().

Pre-requisite for clean MDEV-18450 solution.

FIXME: Properly resolve conflicts between MDEV-18883
and MDEV-7742/MDEV-8305, and record the correct result for
main.log_slow

Do not init lex before choosing main select.

If a splittable materialized derived table / view T is used in a inner nest
of an outer join with impossible ON condition then T is marked as a
constant table. Yet the execution plan to build T is still searched for
in spite of the fact that is not needed. So it should be set.

Lesson learned: A HA_TOPTION_SYSVAR that is bound to
MYSQL_THDVAR_UINT does not have the type uint, but ulonglong.

Only starting with MariaDB 10.3.8 (MDEV-16365), InnoDB can actually
handle ALTER IGNORE TABLE correctly when introducing a NOT NULL
attribute to a column that contains a NULL value. Between
MariaDB Server 10.0 and 10.2, we would incorrectly return an error
for ALTER IGNORE TABLE when the column contains a NULL value.

MDEV-18806 Synchronize ALTER TABLE EXCHANGE PARTITION and PURGE grammar in sql_yacc.yy and sql_yacc_ora.yy

Timeout values in galera_2x3nodes.cnf made cluster startup
unreliable. Tweaked timeout values for more reliable cluster start.

Fixed restart_parameters in galera_sr_mysqldump_sst.

With wsrep_gtid_mode=ON, the appropriate commit hooks were not
called in all cases for applied streaming transactions.

As a fix, removed all special handling of commit order critical
section from Wsrep_high_priority_service and Wsrep_storage_service.
Now commit order critical section is always entered in ha_commit_trans().

Check for wsrep_run_commit_hook is now done in handler.cc, log.cc.
This makes it explicit that the transaction is an active wsrep
transaction which must go through commit hooks.

The test is based in the testcase attached in Jira MDEV.

don't do anything special for stored generated columns
in MyISAM repair code.

add an assert that if there are virtual indexed columns, they
_must_ be beyond the file->s->base.reclength boundary

after mysql_real_data_home was updated in get_options()

* fix CRL tests to work
* regenerate certificates to be at least 2048 bit
  (fixes buster and rhel8 in buildbot)
* update generate-ssl-cert.sh to generate crl files
* make all SSL tests to use certificates generated
  in generate-ssl-cert.sh, remove unused certificates

Backport from 10.4 9c60535f

when deleting a package, delete up to the next empty line,
instead of relying on a package description being of
some fixed number of lines long

On an error (such as when an index cannot be dropped due to
FOREIGN KEY constraints), the field dict_index_t::to_be_dropped
was only being cleared in debug builds, even though the field
is available and being used also in non-debug builds.

This was a regression that was introduced by myself originally
in MySQL 5.7.6 and later merged to MariaDB 10.2.2, in
https://github.com/mysql/mysql-server/commit/d39898de8e0de21f64ce94cd4ea698675edfb447

An error manifested itself in the MariaDB Server 10.4 non-debug build,
involving instant ADD or DROP column. Because an earlier failed
ALTER TABLE operation incorrectly left the dict_index_t::to_be_dropped
flag set, the column pointers of the index fields would fail to be
adjusted for instant ADD or DROP column (MDEV-15562). The instant
ADD COLUMN in MariaDB Server 10.3 is unlikely to be affected by a
similar scenario, because dict_table_t::instant_add_column() in 10.3
is applying the transformations to all indexes, not skipping
to-be-dropped ones.

When the chosen execution plan accesses a join table employing a range
rowid filter a quick select to scan this range has to be built. This
quick select is built by a call of SQL_SELECT::test_quick_select().
At this call the function should allow to evaluate only single index
range scans. In order to be able to do this a new parameter was added
to this function.

The problem with the InnoDB table attribute encryption_key_id is that it is
not being persisted anywhere in InnoDB except if the table attribute
encryption is specified and is something else than encryption=default.
MDEV-17320 made it a hard error if encryption_key_id is specified to be
anything else than 1 in that case.

Ideally, we would always persist encryption_key_id in InnoDB. But, then we
would have to be prepared for the case that when encryption is being enabled
for a table whose encryption_key_id attribute refers to a non-existing key.

In MariaDB Server 10.1, our best option remains to not store anything
inside InnoDB. But, instead of returning the error that MDEV-17320
introduced, we should merely issue a warning that the specified
encryption_key_id is going to be ignored if encryption=default.

To improve the situation a little more, we will issue a warning if
SET [GLOBAL|SESSION] innodb_default_encryption_key_id is being set
to something that does not refer to an available encryption key.

Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the
table definition from InnoDB side when the encryption is being enabled,
and actually fix the root cause of what was reported in MDEV-17320.

1. Always drop merged_for_insert flag on cleanup (there could be errors which prevent TABLE to be assigned)
2. Make more precise cleanup of select parts which was touched

st_select_lex::handle_derived() and mysql_handle_list_of_derived() had
exactly the same implementations.

- Adding a new method LEX::handle_list_of_derived() instead
- Removing public function mysql_handle_list_of_derived()
- Reusing LEX::handle_list_of_derived() in st_select_lex::handle_derived()

Replaced debug to debug_dbug on 10.1 on galera suite. Nothing to do
in wsrep and galera_3nodes suites.