TIMESTAMP columns were compared as strings in ALL/ANY comparison,
which did not work well near DST time change.

Changing ALL/ANY comparison to use "Native" representation to compare
TIMESTAMP columns, like simple comparison does.

Ever since commit 09177ead
the test innodb.row_format_redundant cannot work when the
data file was created with innodb_checksum_algorithm=full_crc32.

Backport of 10.5 commit a9d0bb12

Even though commit b817afaa passed
the test mariabackup.compress_qpress, that test turned out to be
too small to reveal one more problem that had previously been prevented
by the existence of ctrl_mutex. I did not realize that there can be
multiple concurrent callers to compress_write(). One of them is the
log copying thread; further callers are data file copying threads
(default: --parallel=1).

By default, there is only one compression worker thread
(--compress-threads=1).

compress_write(): Fix a race condition between threads that would
use the same worker thread object. Make thd->data_avail contain the
thread identifier of the submitter, and add thd->avail_cond to
notify other compress_write() threads that are waiting for a slot.

   - While creating a new InnoDB segment, allocates the extent
before allocating the inode or page allocation even though
the pages are present in fragment segment. This patch does
reserve the extent when InnoDB ran out of fragment pages
in the tablespace.

ha_spider::field_exchange() returns NULL and that results in a crash
or a assertion failure in spider_db_open_item_ident().

In the first place, there seems to be no need to call field_exchange()
for printing an identity (column name with alias). Thus, we simply
remove the call.

Analysis: JSON_VALUE() returns "null" string instead of NULL pointer.
Fix: When the type is JSON_VALUE_NULL (which is also a scalar) set
null_value to true and return 0 instead of returning string.

The file is now empty and thus serves no purpose.

first SIGTERM and if the process didn't die in 10 seconds, SIGKILL it.

This allows various tools like `rr`, `gcov`, `gprof`, etc to flush
their data to disk properly

MDEV-23149 Server crashes in my_convert / ErrConvString::ptr / Item_char_typecast::check_truncation_with_warn

--log-slow-queries was removed in 10.0. Now opt_slow_logname
can be set either with --slow-query-log-file or with --log-basename


--log was removed in 10.0. Now opt_logname
can be set either with --general-log-file or with --log-basename

When creating a recursive CTE, the column types are taken from the
non recursive part of the CTE (this is according to the SQL standard).

This patch adds code to abort the CTE if the calculated values in the
recursive part does not fit in the fields in the created temporary table.

The new code only affects recursive CTE, so it should not cause any notable
problems for old applications.

Other things:
- Fixed that we get correct row numbers for warnings generated with
  WITH RECURSIVE

Reviewer: Alexander Barkov <bar@mariadb.com>

Disable for embedded as mysqldump cannot connect to embedded server.

Part #2: make sure we allocate space for two JOIN_TABs that
use temporary tables.
The dbug_join_tab_array_size is still set to catch cases where
we try to access more JOIN_TAB object than we thought we would have.

The problem was caused by use of COLLATION(AVG('x')). This is an
item whose value is a constant.
Name Resolution code called convert_const_to_int() which removed AVG('x').
However, the item representing COLLATION(...) still had with_sum_func=1.

This inconsistent state confused the code that handles grouping and
DISTINCT: JOIN::get_best_combination() decided to use one temporary
table and allocated one JOIN_TAB for it, but then
JOIN::make_aggr_tables_info() attempted to use two and made writes
beyond the end of the JOIN::join_tab array.

The fix:
- Do not replace constant expressions which contain aggregate functions.
- Add JOIN::dbug_join_tab_array_size to catch attempts to use more
  JOIN_TAB objects than we've allocated.

- query->intersection fails to get freed if the query exceeds
innodb_ft_result_cache_limit

- errors from init_ftfuncs were not propogated by delete command

This is taken from percona/percona-server@ef2c0bcb9a34aeb06de0058d7c2a2969416b35a7

This bug manifested itself for INSERT...SELECT and DELETE statements whose
WHERE condition used an IN/ANY/ALL predicand or a EXISTS predicate with
such grouping subquery that:
 - its GROUP BY clause could be eliminated,
 - the GROUP clause contained a subquery over a mergeable derived table
   referencing the updated table.

The bug ultimately caused a server crash when the prepare phase of the
statement processing was executed. This happened after removal redundant
subqueries used in the eliminated GROUP BY clause from the statement tree.
The function that excluded the subqueries from the did not do it properly.
As a result the specification of any derived table contained in a removed
subquery was not marked as excluded.

Approved by Oleksandr Byelkin <sanja@mariadb.com>

mysqlimport starts many worker threads. when one of the worker
encounters an error, it frees global memory and calls exit().

it suppresses memory leak detector, because, as the comment says
"dirty exit, some threads are still running", indeed, it cannot
free the memory from other threads.

but precisely because some threads are still running, they
might use this global memory, so it cannot be freed.

fix: if we know that some threads are still running and accept
that we cannot free all memory anyway, let's not free global
allocations either

This is particularly important for Azure where there is no
MyISAM support in their MariaDB cloud product.

Like mysqldumper does, a view can satisfy the requirement
like a table, without constraints. The views in frm files are
text form and don't have column limits.

Thanks Thomas Casteleyn for the suggestion.