In is_eits_usable(), we disable an assertion that fails due to
MDEV-19334.

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Simplified away XA_NOTR, use XID_STATE::is_explicit_XA() instead.

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Let xid_cache_insert()/xid_cache_delete() handle xa_state.

Let session tracker use is_explicit_XA() rather than xa_state != XA_NOTR.

Fixed open_tables() to refuse data access in XA_ROLLBACK_ONLY state.

Removed dead code from THD::cleanup(). It was supposed to be a reminder,
but it got messed up over time.

spider_internal_start_trx() is called either with XA_NOTR or XA_ACTIVE,
which is guarded by server callers. Thus is_explicit_XA() is acceptable
replacement for XA_ACTIVE check (which was likely wrong anyway).

Setting xa_state to XA_PREPARED in spider_internal_xa_prepare() isn't
meaningful, as this value is never accessed later. It can't be accessed
by current thread and it can't be recovered either. It can only be
accessed by spider internally, which never happens.

Make spider_xa_lock()/spider_xa_unlock() static.

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

XID_STATE::rm_error is never used by internal 2PC, it is intended to be
used by explicit XA only.

Also removed redundant xid reset from THD::init_for_queries(). Must've
been done already either by THD::transaction constructor or by
THD::cleanup().

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Part of MDEV-7974 - backport fix for mysql bug#12161 (XA and binlog)

Adding new virtual methods in Field:
- make_empty_rec_store_default_value()
- make_empty_rec_reset()

This simplifies the logic for every Field type,
and makes the code more friendly to pluggable data types.

InnoDB could return the same list again and again if the buffer
passed to trx_recover_for_mysql() is smaller than the number of
transactions that InnoDB recovered in XA PREPARE state.

We introduce the transaction state TRX_PREPARED_RECOVERED, which
is like TRX_PREPARED, but will be set during trx_recover_for_mysql()
so that each transaction will only be returned once.

Because init_server_components() is invoking ha_recover() twice,
we must reset the state of the transactions back to TRX_PREPARED
after returning the complete list, so that repeated traversals
will see the complete list again, instead of seeing an empty list.
Without this tweak, the test main.tc_heuristic_recover would hang
in MariaDB 10.1.

            failed in compare_order_elements function

The issue here is the function compare_order_lists() is called for the order by list of the window functions
so that those window function that can be computed together are adjacent.
So in the function compare_order_list we iterate over all the elements in the order list of the two functions and
compare the items in their order by clause.
The function compare_order_elements() is called for each item in the
order by clause. This function assumes that all the items that are in the order by list would be of the type
Item::FIELD_ITEM.

The case we have is that we have constants in the order by clause. We should ignore the constant and only compare
items of the type Item::FIELD_ITEM in compare_order_elements()

Problem:
========
The mysqlbinlog tool is leaking memory, causing failures in various tests when
compiling and testing with AddressSanitizer or LeakSanitizer like this:

cmake -DCMAKE_BUILD_TYPE=Debug -DWITH_ASAN:BOOL=ON /path/to/source
make -j$(nproc)
cd mysql-test
ASAN_OPTIONS=abort_on_error=1 ./mtr --parallel=auto rpl.rpl_row_mysqlbinlog

CURRENT_TEST: rpl.rpl_row_mysqlbinlog

Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x4eff87 in __interceptor_malloc (/dev/shm/5.5/client/mysqlbinlog+0x4eff87)
#1 0x60eaab in my_malloc /mariadb/5.5/mysys/my_malloc.c:41:10
#2 0x5300dd in Log_event::read_log_event(char const*, unsigned int, char const**,
   Format_description_log_event const*, char) /mariadb/5.5/sql/log_event.cc:1568:
#3 0x564a9c in dump_remote_log_entries(st_print_event_info*, char const*)
/mariadb/5.5/client/mysqlbinlog.cc:1978:17

Analysis:
========
'mysqlbinlog' tool is being used to read binary log events from a remote server.
While reading binary log, if a fake rotate event is found following actions are
taken.

If 'to-last-log' option is specified, then fake rotate event is processed.
In the absence of 'to-last-log' skip the fake rotate event.

In this skipped case the fake rotate event object is not getting cleaned up
resulting in memory leak.

Fix:
===
Cleanup the fake rotate event.

This issues is already fixed in MariaDB 10.0.23 and higher versions as part of
commit c3018b0f

           with GROUP BY + ORDER BY

The method JOIN::create_postjoin_aggr_table() should not call
call JOIN::add_sorting_to_table() unless the first non-constant join
table is passed as the first parameter to the method.

dict_create_foreign_constraints_low(): Tolerate the keywords
IGNORE and ONLINE between the keywords ALTER and TABLE.

We should really remove the hacky FOREIGN KEY constraint parser
from InnoDB.

Otherwise, it is possible for "prepare" to exit with error code 0,
even if it did not work at all.

MDEV-9465 The constructor StringBuffer(const char *str, size_t length, const CHARSET_INFO *cs) looks suspicious

Removing the suspicious constructor, it's not used in the code anyway.

The command SHOW INDEXES ignored setting of the system variable
use_stat_tables to the value of 'preferably' and and showed statistical
data received from the engine. Similarly queries over the table
STATISTICS from INFORMATION_SCHEMA ignored this setting. It happened
because the function fill_schema_table_by_open() did not read any data
from statistical tables.

In the case of error when object shapes are half-collected we need
to set the NULL at the vertice's list.

The bug appears because not all conditions are found to be knowingly
true or false in WHERE after HAVING pushdown optimization.
Impossible WHERE can be found much earlier compared with how it is done now.

To fix it and_new_conditions_to_optimized_cond() is changed.

A sequence of <digits>e<mbhead><mbtail>, e.g.:

  SELECT 123eXYzzz FROM t1;

was not scanned correctly (where XY is a multi-byte character).

The multi-byte head byte X was appended to 123e separately from
the multi-byte tail byte Y, so a pointer to "Yzzz" was passed
into scan_ident_start(), which failed on a bad multi-byte sequence.

After this change, scan_ident_start() gets a pointer to "XYzzz",
so it correctly sees the whole multi-byte character.

           `sel->quick' failure in JOIN::make_range_rowid_filters upon query
           with rowid_filter=ON

Index ranges can be defined using conditions with inexpensive subqueries.
Such a subquery is evaluated when some representation of a possible range
sequence is built. After the evaluation the JOIN structure of the subsquery is distroyed.
Any attempt to build the above representation may fail because the
function that checks whether a subquery is inexpensive in some cases uses
the join structure of the subquery.
When a range rowid filter is built by a range sequence constructed out of
a range condition that uses an inexpensive subquery the representation of
the the sequence is built twice. Building the second representation fails
due to the described problem with the execution of Item_subselect::is_expensive().
The function was corrected to return the result of the last its invocation
if the Item_subselect object has been already evaluated.

Backporting from 10.4 to 10.3: MDEV-17325 NULL-ability problems with LEAST() in combination with NO_ZERO_DATE and NO_ZERO_IN_DATE

This also fixes:
MDEV-17299 Assertion `maybe_null' failed in make_sortkey

Note, during merge of the 10.1 version of MDEV-17299,
please use the 10.3 version of the code (i.e. null merge the 10.1 version).

MDEV-18096 The server would crash when has configs rpl_semi_sync_master_enabled = OFF rpl_semi_sync_master_wait_no_slave = OFF

The patch fixes a fired assert in the semisync master module. The assert
caught attempt to switch semisync off (per rpl_semi_sync_master_wait_no_slave = OFF)
when it was not even initialized (per rpl_semi_sync_master_enabled = OFF).
The switching-off execution branch is relocated under one that executes
enable_master() first.

A minor cleaup is done to remove the int return from two functions that
did not return anything but an error which could not happen in the functions.

Problem was that wrong key_info variable was used, which caused UNIQUE
key to be used as a covering key

Problem was that DBUG_FIX_WRITE_SET was not enabled when using
DBUG_ASSERT_AS_PRINTF

The compile-time option IBUF_COUNT_DEBUG has not been used for years.
It would only work with up to 3 created .ibd files, with no buffered
changes existing while InnoDB is started up.

MDEV-17297: stats.records=0 for a table of Archive engine when it has rows, when we run ANALYZE command

Archive storage engine assumed that any query that attempts to read from
the table will call ha_archive::info() beforehand. ha_archive would flush
un-written data in that call (this would make it visible for the reads).

Break this assumption. Flush the data when the table is opened for reading.

This way, one can do multiple write statements without causing a flush, but
as soon as we might need the data, we flush it.

Do not attempt to set param->table->with_impossible_ranges if the
range optimizer is using pseudo-indexes (which is true when we are
computing EITS selectivity estimates or doing partition pruning).

DROP DATABASE would internally execute DROP TABLE on every contained
table and finally remove the directory. In InnoDB, DROP TABLE is
sometimes executed in the background. The table would be renamed to
a name that starts with #sql. The existence of these files would
prevent DROP DATABASE from succeeding.

CREATE OR REPLACE DATABASE can internally execute DROP DATABASE if
the directory already exists. This could fail due to the InnoDB
background DROP TABLE, possibly due to some tables that were
leftovers from earlier tests.

Do not try to compile threadpool_common.cc, if threadpool is not available
on current OS.

Also introduced undocumented/uncached CMake variable DISABLE_THREADPOOL,
to emulate builds on exotic OSes.