Problem:- In replication if slave has extra persistent column then these
column are not computed while applying write-set from master.

Solution:- While applying row events from server, we will generate values
for extra persistent columns.

fil_space_t::recv_size: New member: recovered tablespace size in pages;
0 if no size change was read from the redo log,
or if the size change was implemented.

fil_space_set_recv_size(): New function for setting space->recv_size.

innodb_data_file_size_debug: A debug parameter for setting the system
tablespace size in recovery even when the redo log does not contain
any size changes. It is hard to write a small test case that would
cause the system tablespace to be extended at the critical moment.

recv_parse_log_rec(): Note those tablespaces whose size is being changed
by the redo log, by invoking fil_space_set_recv_size().

innobase_init(): Correct an error message, and do not require a larger
innodb_buffer_pool_size when starting up with a smaller innodb_page_size.

innobase_start_or_create_for_mysql(): Allow startup with any initial
size of the ibdata1 file if the autoextend attribute is set. Require
the minimum size of fixed-size system tablespaces to be 640 pages,
not 10 megabytes. Implement innodb_data_file_size_debug.

open_or_create_data_files(): Round the system tablespace size down
to pages, not to full megabytes, (Our test truncates the system
tablespace to more than 800 pages with innodb_page_size=4k.
InnoDB should not imagine that it was truncated to 768 pages
and then overwrite good pages in the tablespace.)

fil_flush_low(): Refactored from fil_flush().

fil_space_extend_must_retry(): Refactored from
fil_extend_space_to_desired_size().

fil_mutex_enter_and_prepare_for_io(): Extend the tablespace if
fil_space_set_recv_size() was called.

The test case has been successfully run with all the
innodb_page_size values 4k, 8k, 16k, 32k, 64k.

Allocate password hash in statment memory

MDEV-11656: 'Data structure corruption' IMPORT TABLESPACE doesn't work for encrypted InnoDB tables if space_id changed

Problem was that for encryption we use temporary scratch area for
reading and writing tablespace pages. But if page was not really
decrypted the correct updated page was not moved to scratch area
that was then written. This can happen e.g. for page 0 as it is
newer encrypted even if encryption is enabled and as we write
the contents of old page 0 to tablespace it contained naturally
incorrect space_id that is then later noted and error message
was written. Updated page with correct space_id was lost.

If tablespace is encrypted we use additional
temporary scratch area where pages are read
for decrypting readptr == crypt_io_buffer != io_buffer.

Destination for decryption is a buffer pool block
block->frame == dst == io_buffer that is updated.
Pages that did not require decryption even when
tablespace is marked as encrypted are not copied
instead block->frame is set to src == readptr.

If tablespace was encrypted we copy updated page to
writeptr != io_buffer. This fixes above bug.

For encryption we again use temporary scratch area
writeptr != io_buffer == dst
that is then written to the tablespace

(1) For normal tables src == dst ==  writeptr
ut_ad(!encrypted && !page_compressed ?
	src == dst && dst == writeptr + (i * size):1);
(2) For page compressed tables src == dst == writeptr
ut_ad(page_compressed && !encrypted ?
	src == dst && dst == writeptr + (i * size):1);
(3) For encrypted tables src != dst != writeptr
ut_ad(encrypted ?
	src != dst && dst != writeptr + (i * size):1);

Replace all exit() calls in InnoDB with abort() [possibly via ut_a()].
Calling exit() in a multi-threaded program is problematic also for
the reason that other threads could see corrupted data structures
while some data structures are being cleaned up by atexit() handlers
or similar.

In the long term, all these calls should be replaced with something
that returns an error all the way up the call stack.

MTR raises default wait_for_pos_timeout from 300 to 1500 when tests
are run with valgrind. The same needs to be done for other
replication-related waits

Make some global fil_crypt_ variables static.

fil_close(): Call mutex_free(&fil_system->mutex) also in InnoDB, not
only in XtraDB. In InnoDB, sync_close() was called before fil_close().

innobase_shutdown_for_mysql(): Call fil_close() before sync_close(),
similar to XtraDB shutdown.

fil_space_crypt_cleanup(): Call mutex_free() to pair with
fil_space_crypt_init().

fil_crypt_threads_cleanup(): Call mutex_free() to pair with
fil_crypt_threads_init().

Try to stabilize test cases. These test behave badly when run in certain order.

The reason was that the test was reusing the same log file without deleting it between tests.
Fixed by creating a new log file as part of the test

  Problem:- While running individual tests of Galera_3nodes ,
  We get warnings like '[Warning] WSREP: Could not open state file
  for reading: '. And because of this individual tests fails.

  Solution:- We change suite.pm of Galera_3nodes to supress these warnings.

Essentially revert MDEV-6759, which addressed a double free of memory
by removing the freeing altogether, introducing the memory leaks.
No double free was observed when running the test suite -DWITH_ASAN.

Replace some mem_heap_free(foreign->heap) with dict_foreign_free(foreign)
so that the calls can be located and instrumented more easily when needed.

mysql_release.cmake set WITH_JEMALLOC=static, which makes windows
builds fail since there is no jemalloc either static or shared there

Updated sysvars_wsrep.result file.

In file sql/opt_range.cc,when calculate_cond_selectivity_for_table() is called with optimizer_use_condition_selectivity=4 then
	- thd->no_errors is set to 1
	- the original value of thd->no_error is not restored to its original value
	- this is causing the assertion to fail in the subsequent queries

Fixed by restoring the original value of thd->no_errors

     Tasks:-
         Changes in wsrep_dirty_reads variable
         1.) Global + Session scope (Current: session-only)
         2.) Can be set using command line.
         3.) Allow all commands that do not change data (besides SELECT)
         4.) Allow prepared Statements that do not change data
         5.) Works with wsrep_sync_wait enabled

This reverts commit 7ed5563b.

Reduce the number of calls to encryption_get_key_get_latest_version
when doing key rotation with two different methods:

(1) We need to fetch key information when tablespace not yet
have a encryption information, invalid keys are handled now
differently (see below). There was extra call to detect
if key_id is not found on key rotation.

(2) If key_id is not found from encryption plugin, do not
try fetching new key_version for it as it will fail anyway.
We store return value from encryption_get_key_get_latest_version
call and if it returns ENCRYPTION_KEY_VERSION_INVALID there
is no need to call it again.

After applying/replaying the transaction, the memory that
stored the query string was also wrongly freed.

... causes MariaDB to crash

On error, the wsrep replication buffer (binlog) is dumped to a file
to aid investigations. In order to also include the binlog header,
FDLE object is also needed. This object is only available for wsrep-
threads.
Fix: Instantiate an FDLE object for non-wsrep threads.

Add 'which' to REQUIRES list.

Role names with trailing whitespaces are truncated in length as of
956e92d9 to fix MDEV-8609. The problem
is that the code that creates role mappings expects the string to be null
terminated.

Add the null terminator to account for that as well. In the future
the rest of the code can be cleaned up to never assume c style strings
but only LEX_STRINGS.

        Functions from sql/statistics.cc don't seem to expect
        stat tables to fail or to have inadequate structure.
        Table open errors suppressed and some validity
        checks added. Invalid tables reported to the server
        log.

MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))

Different fix. Don't allow Item_func_sp to be evaluated unless
all tables are prelocked.

Extend the test case to make sure Item_func_sp::val_str is called
(the table must have at least one row for that).

Revert "MDEV-10713: signal 11 error on multi-table update - crash in handler::increment_statistics or in make_select or assertion failure pfs_thread == ((PFS_thread*) pthread_getspecific((THR_PFS)))"

This reverts commit 035a5ac6.

Two minor problems and one regression:
1. caching the value in str_result. Other Item methods may use it,
   destroying the cache. See, for example, Item::save_in_field, where
   str_result is moved to use a local buffer (this failed main.grant)
2. Item_func_conv_charset::safe is now set too late, it's initialized
   only in val_str() but checked before that, this failed many tests
   in optimized builds.

to fix 1 - use tmp_result instead of str_result, to fix 2, use
the else branch in the Item_func_conv_charset constructor to set
safe purely from charset properties.

But this introduces a regression, constant strings can no longer be
converted, say, from utf8 to latin1 (because 'safe' will be false).
This fails few tests too. There is no way to fix it without reverting
the commit and converting constants, as before, in the constructor.

The race condition happened if mark_xid_done was considerably delayed,
and an extra Binlog_checkpoint event was written into the binary log
which was later indicated in an error message. Fixed by ensuring
that the event is written before the binary log is rotated to the one
which is used in the output.

The reason is a simple race condition. Initially the test was meant to synchronize with master
before showing tables, but it turned out that the slave IO thread should fail by this point,
and synchronization was removed along with a server bugfix. Now added an intermediate sync
instead, to make sure that slave has replicated events before the point of failure

MDEV-11162 Assertion `num_records == m_idx_array.size()' failed in Filesort_buffer::alloc_sort_buffer(uint, uint)

Updating result for the group_by_innodb.test

MDEV-11162 Assertion `num_records == m_idx_array.size()' failed in Filesort_buffer::alloc_sort_buffer(uint, uint)

When JOIN::destroy() is called for a JOIN object that has
   - join->tmp_join != NULL
   - also has join->table[0]->sort

then the latter was not cleaned up.
This could cause a memory leak and/or asserts in the subsequent queries.

Fixed by adding a cleanup call.