Server and command line tools now support option --tls_version to specify the
TLS version between client and server. Valid values are TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
or a combination of them. E.g.

--tls_version=TLSv1.3
--tls_version=TLSv1.2,TLSv1.3

In case there is a gap between versions, the lowest version will be used:
--tls_version=TLSv1.1,TLSv1.3 -> Only TLSv1.1 will be available.

If the used TLS library doesn't support the specified TLS version, it will use
the default configuration.

Limitations:

SSLv3 is not supported. The default configuration doesn't support TLSv1.0 anymore.
TLSv1.3 protocol currently is only supported by OpenSSL 1.1.0 (client and server) and
GnuTLS 3.6.5 (client only).

Overview of TLS implementations and protocols

Server:

+-----------+-----------------------------------------+
| Library   | Supported TLS versions                  |
+-----------+-----------------------------------------+
| WolfSSL   | TLSv1.1, TLSv1,2                        |
+-----------+-----------------------------------------+
| OpenSSL   | (TLSv1.0), TLSv1.1, TLSv1,2, TLSv1.3    |
+-----------+-----------------------------------------+
| LibreSSL  | (TLSv1.0), TLSv1.1, TLSv1,2, TLSv1.3    |
+-----------+-----------------------------------------+

Client (MariaDB Connector/C)
+-----------+-----------------------------------------+
| Library   | Supported TLS versions                  |
+-----------+-----------------------------------------+
| GnuTLS    | (TLSv1.0), TLSv1.1, TLSv1.2, TLSv1.3    |
+-----------+-----------------------------------------+
| Schannel  | (TLSv1.0), TLSv1.1, TLSv1.2             |
+-----------+-----------------------------------------+
| OpenSSL   | (TLSv1.0), TLSv1.1, TLSv1,2, TLSv1.3    |
+-----------+-----------------------------------------+
| LibreSSL  | (TLSv1.0), TLSv1.1, TLSv1,2, TLSv1.3    |
+-----------+-----------------------------------------+

MDEV-16249 CHECKSUM TABLE for a spider table is not parallel and saves all data in memory in the spider head by default (#1328)

followup for be5c432a

ha_partition::calculate_checksum() has to invoke calculate_checksum()
for partitions unconditionally, not under (HA_HAS_OLD_CHECKSUM | HA_HAS_NEW_CHECKSUM).
Because the server uses ::info() to ask for a live checksum, while
calculate_checksum() must, precisely, calculate it the slow way,
also for tables that don't have the live checksum at all.

Also, fix the compilation on Windows (ha_checksum/ulonglong type mix).

Introduced a print_key_value function to makes sure that the trace prints data in readable format
for readable characters and the rest of the characters are printed as hexadecimal.

Older GCC generates SSE instruction on not-128-bit-aligned data in
Bitmap<128>::buffer

Workaround by forcing GCC not to use SSE on Bitmap<N> template.

MDEV-16249 CHECKSUM TABLE for a spider table is not parallel and saves all data in memory in the spider head by default (#1328)

add checksum_null for setting null value of checksum

MDEV-18788 Live upgrade from MySQL 5.6/5.7 to MariaDB 10.4 fails with "Event Scheduler: An error occurred when initializing system tables"

if columns or indexes are modified/renamed/dropped in an ALTER TABLE,
stat tables must be updated accordingly (e.g. all statistics for a column
should be dropped). But if a stat table doesn't exist, it's not a reason
to fail the whole ALTER TABLE operation - such an error should be ignored.

comments, rename a function to reflect its usage better

Using different recommended speedup options for WolfSSL.

- Enable  x64 assembly code on Intel.
- in my_crypt.cc, align EVP_CIPHER_CTX buffer, since some members need
alignment of 16 (for AESNI instructions), when assembler is enabled.
- Adjust MY_AES_CTX_SIZE
- Enable fastmath in wolfssl (large integer math).

client-certkey.pem contains both certificate and corresponding
private key.

row_search_mvcc(): Duplicate the logic of btr_pcur_move_to_next()
so that an infinite loop can be avoided when advancing to the next
page fails due to a corrupted page.

Also, --skip-innodb-buffer-pool-load-at-startup to avoid a crash
in buf_load() due to loading pages that we are corrupting intentionally.

Apprently, sometimes there will be null pointers with 0 length
passed to the MyCTX::update() function, and  will need to return
a valid buffer.

So weaken the assertion, and use a valid pointer for src if it was NULL.

At higher levels of innodb_force_recovery, the InnoDB transaction
subsystem will not be set up at all.

At slightly lower levels, recovered transactions will not be rolled back,
and DDL operations could hang due to locks being held at all.

Let us consistently refuse all writes if the predicate
high_level_read_only holds. We failed to refuse DROP TABLE
and DROP DATABASE. (Refusing DROP TABLE is a partial backport
from MDEV-19570 in the 10.5 branch.)

- Replace mysql_version check with omit_virtual_cols() in
ha_innobase::check_if_supported_inplace_alter().

- If one of the encryption threads already started the initialization
of the tablespace then don't remove the other uninitialized tablespace
from the rotation list.

- If there is a change in innodb_encrypt_tables then
don't remove the processed tablespace from rotation list.

LOCK_global_system_variables: Declare with MYSQL_PLUGIN_IMPORT

Changed the function append_range_all_keyparts to use sel_arg_range_seq_init / sel_arg_range_seq_next to produce ranges.
Also adjusted to print format for the ranges, now the ranges are printed as:
    (keypart1_min, keypart2_min,..)  OP (keypart1_name,keypart2_name, ..) OP (keypart1_max,keypart2_max, ..)

Also added more tests for range and index merge access for optimizer trace

- Don't apply redo log for the corrupted page when innodb_force_recovery > 0.
- Allow the table to be dropped when index root page is
corrupted when innodb_force_recovery > 0.

The update callback functions for several settable global InnoDB variables
are acquiring InnoDB latches while holding LOCK_global_system_variables.

On the other hand, some InnoDB code is invoking THDVAR() while holding
InnoDB latches. An example of this is thd_lock_wait_timeout() that is
called by lock_rec_enqueue_waiting(). In some cases, the
intern_sys_var_ptr() that is invoked by THDVAR() may acquire
LOCK_global_system_variables, via sync_dynamic_session_variables().

In lock_rec_enqueue_waiting(), we really must be holding some InnoDB
latch while invoking THDVAR(). This implies that
LOCK_global_system_variables must conceptually reside below any InnoDB
latch in the latching order. That in turns implies that the various
update callback functions must release LOCK_global_system_variables
before acquiring any InnoDB mutexes or rw-locks, and reacquire
LOCK_global_system_variables later. The validate functions are being
invoked while not holding LOCK_global_system_variables and thus they
do not need any changes.

The following statements are affected by this:

SET GLOBAL innodb_adaptive_hash_index = …;
SET GLOBAL innodb_cmp_per_index_enabled = 1;
SET GLOBAL innodb_old_blocks_pct = …;
SET GLOBAL innodb_fil_make_page_dirty_debug = …; -- debug builds only
SET GLOBAL innodb_buffer_pool_evict = uncompressed; -- debug builds only
SET GLOBAL innodb_purge_run_now = 1; -- debug builds only
SET GLOBAL innodb_purge_stop_now = 1; -- debug builds only
SET GLOBAL innodb_log_checkpoint_now = 1; -- debug builds only
SET GLOBAL innodb_buf_flush_list_now = 1; -- debug builds only
SET GLOBAL innodb_buffer_pool_dump_now = 1;
SET GLOBAL innodb_buffer_pool_load_now = 1;
SET GLOBAL innodb_buffer_pool_load_abort = 1;
SET GLOBAL innodb_status_output = …;
SET GLOBAL innodb_status_output_locks = …;
SET GLOBAL innodb_encryption_threads = …;
SET GLOBAL innodb_encryption_rotate_key_age = …;
SET GLOBAL innodb_encryption_rotation_iops = …;
SET GLOBAL innodb_encrypt_tables = …;
SET GLOBAL innodb_disallow_writes = …;

buf_LRU_old_ratio_update(): Correct the return type.