Move the heuristic as requested. Make it use the user-settable parameter

Fix tests.

Part #4:
- Fix comment
- Make tree pruning visible in the optimizer trace.

Part #3: Introduce a user-visible @@optimizer_max_sel_arg_weight
to control the optimization.

Part #2: Add debug code to verify SEL_ARG graph weight

(Variant #2)
Do not produce SEL_ARG graphs that would yield huge numbers of ranges.
Introduce a concept of SEL_ARG graph's "weight". If we are about to
produce a graph whose "weight" exceeds the limit, remove the parts
of SEL_ARG graph that represent the biggest key parts. Do so until
the graph's is within the limit.

Variant #2: Don't call enforce_sel_arg_weight_limit() for sub-graphs,
as this has complicated semantics if the subgraph has shared
sub-sub-graphs. Instead, do pruning it only after we've constructed
the entire SEL_ARG graph.

MDEV-22148 : Assertion `state_ == s_exec || state_ == s_quitting' failed in optimized builds | SIGABRT in wsrep::client_state::disable_streaming

Actual bug seems to be already fixed, just adding a test case.

Add info to the error message how to get details about error which happened.

We can simply use C++11 std::atomic for avoiding undefined behaviour
related to concurrent stores to a shared variable. On most if not all
ISAs, std::memory_order_relaxed loads and stores will not really
differ from non-atomic loads or stores.

In fts_optimize_remove_table(), InnoDB tries to access the
fts_optimize_wq after shutting down the fts optimize thread.
This issue caused by the commit a41d4297.
Fix should check for fts optimize thread shutdown state
before checking fts_optimize_wq.

This has been unused from the very beginning
(mysql/mysql-server@d5e512ae7e37cd1f70c44a3f12205d70b13118ab).

ibuf_merge_or_delete_for_page(): Do not attempt to invoke
ibuf_delete_recs() on a page of the change buffer itself.
The caller could already be holding ibuf->index->lock,
and an attempt to acquire it in S mode would hang the release server
or cause an assertion failure in rw_lock_s_lock_func() in a debug
server.

This problem was reproducible on 1 out of 2 runs of the following:
./mtr --no-reorder \
innodb.innodb-page_compression_default \
innodb.innodb-page_compression_snappy \
innodb.innodb-page_compression_zip \
innodb.innodb_wl6326_big innodb.xa_recovery

This was missed in commit 2c252ba9
(MySQL 5.5.42, MariaDB 5.5.42).

This bug happened when the HEAP temporary table used for the derived table
created for a derived handler of a remote engine of the federated type
became full and was converted to an Area table. For this conversion
the tmp_table_param parameter must be always taken from the select_unit
object created for the result of the derived table.

Fix typo.

MDEV-22277 LeakSanitizer: detected memory leaks in mem_heap_create_block_func after attempt to create foreign key

- During online DDL, prepare phase error handler fails to remove
the memory allocated for newly created foreign keys.

Require galera_have_debug_sync.inc and re-record to include new
variables exposed by latest galera library.

This will update galera_3nodes/disabled.def.

Make open_table() fail if sequence should be opened, but it turns out to
be locked view.

MDEV-22330: mysqlbinlog stops with an error Don't know how to handle column type: 255 meta: 4 (0004)

Analysis:
========
"mysqlbinlog -v" option will reconstruct row events and display them as
commented SQL statements. If this option is given twice, the output includes
comments to indicate column data types and some metadata.
`log_event_print_value` is the function reponsible for printing values and
their types. This function doesn't handle GEOMETRY type. Hence the above error
gets printed.

Fix:
===
Add support for GEOMETRY datatype.

The original code was correct. mysql_upgrade calls the mysql client to
talk with MariaDB. It doesn't call itself!

- During insertion of clustered inde, InnoDB does the check for
foreign key constraints. It rebuild the tuple based on foreign
column names when there is no foreign index. While rebuilding,
InnoDB should ignore the dropped columns.

The original code was correct. mysql_upgrade calls the mysql client to
talk with MariaDB. It doesn't call itself!