MDEV-18015: Assertion `global_status_var.global_memory_used == 0' failed when using UDF , window functions and views

Adding destructor for Group_bound_tracker to free Cached_item_str.
The Cached_item for window functions are allocated on THD:mem_root
but the Cached_item_str has value of type string which is allocated on
the heap, so we need to call free() for it

os_file_write_func() and os_file_read_no_error_handling_func() returned
different result values depending on if UNIV_PFS_IO was defined or not.

Other things:
- Added some comments about return values for some functions

Wrong compiler warning from GCC:
‘snprintf’ output 2 or more bytes (assuming 4001)
into a destination of size 4000

- --default-character-set can now be disabled in mysqldump
- --skip-resolve can be be disabled in mysqld
- mysql_client_test now resets global variables it changes
- mtr couldn't handle [mysqldump] in config files (wrong regexp used)

Do not use TARGET_LINK_LIBRARIES(mysys mysys_ssl),
this means that mysys_ssl is linked to practically everything.

The issue is that two MARIA_HA instances shares the same MARIA_STATUS_INFO
object during UNION execution, so the second MARIA_HA instance state pointer
MARIA_HA::state points to the MARIA_HA::state_save of the first MARIA instance.

This happens in
thr_multi_lock(...) {
...
	for (first_lock=data, pos= data+1 ; pos < end ; pos++)
	{
...
		if (pos[0]->lock == pos[-1]->lock && pos[0]->lock->copy_status)
			(pos[0]->lock->copy_status)((*pos)->status_param,
																	(*first_lock)->status_param);
...
	}
...
}

Usually the state is restored from ha_maria::external_lock(...):

\#0  _ma_update_status (param=0x6290000e6270) at ./storage/maria/ma_state.c:309
\#1  0x00005555577ccb15 in _ma_update_status_with_lock (info=0x6290000e6270) at ./storage/maria/ma_state.c:361
\#2  0x00005555577c7dcc in maria_lock_database (info=0x6290000e6270, lock_type=2) at ./storage/maria/ma_locking.c:66
\#3  0x0000555557802ccd in ha_maria::external_lock (this=0x61d0001b1308, thd=0x62a000048270, lock_type=2) at ./storage/maria/ha_maria.cc:2727

But _ma_update_status() does not take into account the case when
MARIA_HA::status points to the MARIA_HA::state_save of the other MARIA_HA
instance.

The fix is to restore MARIA_HA::state in ha_maria::external_lock() after
maria_lock_database() call for transactional tables.

Removed #! sequence from non-executable script.

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.

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

- 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.

or server crashes in JOIN::fix_all_splittings_in_plan after EXPLAIN

This patch resolves the problem of overflowing when performing
calculations to estimate the cost of an evaluated query execution plan.
The overflowing in a non-debug build could cause different kind of
problems uncluding crashes of the server.

- create_table_def() misconstructs the dict_table_t by ignoring the stored
columns of the table if virtual column is present between stored columns.

Simulation of a big-sized event in rpl.rpl_semi_sync_skip_repl did not clean
up after itself so screw the last binlog event offset which could jump
backwards.
The test is refined to rotate a binlog file with simulation and use the next
one for logics of the test incl master-slave synchonization.

MDEV-14192: mariabackup.incremental_backup failed in buildbot with Failing assertion: byte_offset % OS_FILE_LOG_BLOCK_SIZE == 0

In some cases it's possible that InnoDB redo log file header is re-written so,
that checkpoint lsn and checkpoint lsn offset are updated, but checkpoint
number stays the same. The fix is to re-read redo log header if at least one
of those three parametes is changed at backup start.

Repeat the logic of log_group_checkpoint() on choosing InnoDB checkpoint info
field on backup start. This does not influence backup correctness, but
simplifies bugs analysis.

The INFORMATION_SCHEMA plugin INNODB_SYS_VIRTUAL, which was introduced
in MariaDB 10.2.2 along with the dictionary table SYS_VIRTUAL,
is similar to other, much older and already stable plugins that
provide access to InnoDB dictionary tables.

This patch corrects the patch for the bug 10006. The latter incorrectly
calculates the attribute TABLE_LIST::dep_tables for inner tables
of outer joins that are to be converted into inner joins.
As a result after the patch some valid join orders were not evaluated
and the optimizer could choose an execution plan that was far from
being optimal.

Running trigger_null-8605 drop_bad_db_type tests in this order was
failing due to unremoved temporary files created in trigger_null-8605

The code in best_access_path function, when it does not find a key suitable for ref access
and join_cache_level is set to a value so that hash_join is possible we build a hash key.
Later in the function we compare the cost of ref access with table scan (or index scan
or quick selects). No need to do this when we have got the hash key.