max out parallel purge worker tasks, on slow shutdown, to speedup

When some expression of an INET6 data type involves conversion to INET6 from
other data types, e.g. in:

- CAST:

    SELECT CAST(non_inet6_expr AS INET6)

- CASE and hybrid functions:

    SELECT CASE WHEN expr THEN inet6_expr ELSE non_inet6_expr END

- UNION:

    SELECT inet6_expr UNION SELECT non_inet6_expr

the result column must be fixed as NULL-able even if the non-inet6 expression itself
is not NULL-able, because at the execution time the conversion can fail.

Details:
- Forcing NULL-ability if conversion from some data type to INET6 is involved
  (for non-constant or for expensive expressions).
- Non-expensive constant expressions are tested for NULL-ability at fix_fields() time,
  so things like `CAST('::' AS INET6)` are still detected as NOT NULL.
- Adding "bool warn" parameter into a few methods, to avoid redundant warnings
  at fix_fields() time when calculating NULL-ability of constant values.

fts_optimize_shutdown(): Wait for fts_optimize_callback()
to terminate before deleting the timer that it uses.

The buf_page_free() call that was introduced in MDEV-15528 was
performed too early in fseg_free_page(), tripping a debug check
in ibuf_remove_free_page(). In all other callers, we can (and will)
invoke buf_page_free() right after fseg_free_page(), but in
ibuf_remove_free_page() we will defer that call to the end of the
mini-transaction. (That call was already present.)

btr_pcur_store_position(): Replace a too strict debug assertion.
It is possible to have a clustered index B-tree for a logically
empty table, which will consist of a node pointer from the root
page to a leaf page that contains the metadata record.

The too strict debug assertion was added in
commit 0e5a4ac2 (MDEV-15562).

MDEV-21546 main.backup_stages occasionally fails with lock wait timeout

For field with type INET, during EITS collection the min and max values are store in text
representation in the statistical table.
While retrieving the value from the statistical table, the value is stored back in the original
field using binary form instead of text and this was resulting in the crash.

Introduced 2 functions in the Field structure:
  1) store_to_statistical_minmax_field
  2) store_from_statistical_minmax_field

With MDEV-16678, InnoDB background tasks (most notably, the purge of
committed transaction history) can acquire metadata locks.
Because of this, the lock_wait_timeout=0 is too strict and must
be relaxed.

The test used to fail easily if an extra sleep was added to
the end of dict_table_close(), before the MDL release. Now,
with lock_wait_timeout=1, the test passes even with an extra
0.1-second sleep added to dict_table_close().

Thanks to Monty for providing this fix.

commit f74023b9 (MDEV-15090)
inadvertently removed a mtr_t::commit() call from
trx_undo_report_rename(), causing an InnoDB hang if
we failed to log a RENAME operation.

It is unclear whether this condition is possible in practice.
The test case involved SET GLOBAL innodb_trx_rseg_n_slots_debug=1
and a failed CREATE TABLE...SELECT, whose error handling would
internally invoke RENAME in InnoDB.

log_buf_pool_get_oldest_modification(): Acquire
log_sys_t::flush_order_mutex in order to prevent a race condition
that was introduced in
commit 1a6f708e (MDEV-15058).

Before that change, log_buf_pool_get_oldest_modification()
was protected by both log_sys.mutex and log_sys.flush_order_mutex
like it was supposed to be ever since
commit a52c4820 (MySQL 5.5.10).

buf_pool_t::get_oldest_modification(): Replaces
buf_pool_get_oldest_modification(), to emphasize that
log_sys.flush_order_mutex must be acquired by the caller if needed.

log_close(): Invoke log_buf_pool_get_oldest_modification()
in order to ensure a clean shutdown.

The scenario of the race condition is as follows:

1. The buffer pool is clean (no writes are pending).
2. mtr_add_dirtied_pages_to_flush_list() releases log_sys.mutex.
3. log_buf_pool_get_oldest_modification() observes that the
buffer pool is clean and returns log_sys.lsn.
4. log_checkpoint() completes, writing a wrong checkpoint header
according to which everything up to log_sys.lsn was clean.
5. mtr_add_dirtied_pages_to_flush_list() completes the execution
of mtr_memo_note_modifications(), releases the page latches and
the flush_order_mutex.
6. On a subsequent log_checkpoint(), the assertion could fail
if the page modifications had not been flushed yet.

The failing assertion (which is valid) was added in MySQL 5.7
mysql/mysql-server@5c6c6ec69336369487dfc080a6980089b4e1a3c2
and merged to MariaDB Server 10.2.2 in
commit fec844ac.

exporting data from the server needs MYSQL_PLUGIN_IMPORT.

For character sets and collation where character to weight mapping > 1,
there we need to make sure while creating a sort key,
a temporary buffer is created to store the value of the item by val_str function
and then copy that value back to the sort buffer.
In this case when using a priority queue Sort_param::tmp_buffer was not allocated.

Minor refactoring:
Changed Sort_param::tmp_buffer from char* to String

Problem:
=======
  While evicting the uncompressed page from buffer pool, InnoDB writes
the checksum for the compressed page in buf_LRU_free_page().
So while flushing the compressed page, checksum validation fails
when innodb_checksum_algorithm variable changed to strict_none.

Solution:
========
- Calculate the checksum only during flushing of page. Removed the
checksum write in buf_LRU_free_page().

Compare to trx_roll_crash_recv_trx directly where needed.

innobase_init(): On every path to refused startup, log the reason
to refuse startup as an error, instead of a note.

MENT-458 MTR Big test "spider/bugfix.sql_mode_mariadb & myself" are both failing on Azure MTR pipeline

Support the dash number of MariaDB versions by Spider's tests

Support the dash number of MariaDB versions by Spider's install sequence

Item_sum_sp did not override val_native(). So the reported script
crashed in the default implementation in Item::val_native() on DBUG_ASSERT().

Implementing a correct Item_sum_sp::val_native().

Existing implementation used my_checksum (from mysys)
for calculating table checksum and binlog checksum.

This implementation was optimized for powerpc only and lacked
SIMD implementation for x86 (using clmul) and ARM
(using ACLE) instead used zlib-crc32.

mariabackup had its own copy of the crc32 implementation
using hardware optimized implementation only for x86 and lagged
hardware based implementation for powerpc and ARM.

Patch helps unifies all such calls and help aggregate all of them
using an unified interface my_checksum().

Said unification also enables hardware optimized calls for all
architecture viz. x86, ARM, POWERPC.
Default always fallback to zlib crc32.

Thanks to Daniel Black for reviewing, fixing and testing
PowerPC changes. Thanks to Marko and Daniel for early code feedback.

Disallowing EXTRACT(xxx FROM inet6arg) as fix time.
Adding a new method Type_handler::can_return_extract_source().

The opt_for_user subrule was incorrectly scanned before sp_create_assignment_lex(),
so the user name and the host were created on a wrong memory root.

- Reoganizing the grammar to make sure that sp_create_assignment_lex()
  is called immediately after PASSWORD_SYM is scanned, so all attributes
  are then allocated on its memory root.

- Moving the semantic code as methods to LEX, so the grammar looks as simple as possible.

- Changing text_or_password to be of the data type USER_AUTH*.
  As a side effect, the LEX::definer member is now not used when processing
  the SET PASSWORD statement. Everything is done using Bison's stack.

The bug sas introduced by this commit:
commit bf5a144e

Less error prone, stricter type control.

This couldn't cause any bugs as ptr was zero terminated, but still better
to have the length correct.

This change also affects information_schema.tables

The create table option "transactional=0 | 1" is now always shown for
storage engines that supports both transactional/crash safe tables and
non transactional tables.

Before this patch the transactional=... option was only shown if the user
specified transactional=... in the CREATE TABLE or ALTER TABLE statement.
The reason for the change was to be able to make it easy to know if an Aria
table is transactional or not.