Starting with the Intel Skylake microarchitecture, the PAUSE
instruction latency is about 140 clock cycles instead of earlier 10.
On AMD processors, the latency could be 10 or 50 clock cycles,
depending on microarchitecture.

Because of this big range of latency, let us scale the loops around
the PAUSE instruction based on timing results at server startup.

my_cpu_relax_multiplier: New variable: How many times to invoke PAUSE
in a loop. Only defined for IA-32 and AMD64.

my_cpu_init(): Determine with RDTSC the time to run 16 PAUSE instructions
in two unrolled loops according, and based on the quicker of the two
runs, initialize my_cpu_relax_multiplier. This form of calibration was
suggested by Mikhail Sinyavin from Intel.

LF_BACKOFF(), ut_delay(): Use my_cpu_relax_multiplier when available.

ut_delay(): Define inline in my_cpu.h.

UT_COMPILER_BARRIER(): Remove. This does not seem to have any effect,
because in our ut_delay() implementation, no computations are being
performed inside the loop. The purpose of UT_COMPILER_BARRIER() was to
prohibit the compiler from reordering computations. It was not
emitting any code.

Use correct preprocessor definition.
Do not compare socket value with FD_SETSIZE

The test cases for the MDEV found several independent bugs
in MariaDB server and Aria:
- If a temporary table was marked as crashed, it could never
  be deleted.
- Opening of a crashed temporary table gave an error message
  but the error was never forwarded to the caller which caused
  an assert() in my_ok()
- init_read_record() did mmap of all temporary tables, which is
  probably not a good idea as this area can potentially be
  very big. Changed code to only mmap internal temporary tables.
- mmap-ed tables where not unmapped in case of repair/optimize
  which caused bad data in table and crashes if the original
  table files where replaced with new ones (as the old mmap
  was still in place). Fixed by removing the mmap in case
  of repair.
- Cleaned up usage of code that disabled mmap in Aria

Problem was that in case of implicit rollback for alter table
Aria did try to run commit twice.

The test case for this is tricky to do in 10.2, so it will
be added to 10.4 as part of BACKUP STAGE testing.

MDEV-18940 Galera: Rolling upgrade: all nodes except upgraded node5 failed with Assertion `meta->gtid.seqno == wsrep_thd_trx_seqno(thd)' with SEQUENCEs (#1342)

Empty write sets will not trigger apply callback, and will not
update thread wsrep_trx_meta.gtid.seqno. Because of that assert will
be triggered when commit callback is called.

In collaboration with Sergey Vojtovich <svoj@mariadb.org>

The COMPRESSED clause is now a part of the data type and goes immediately
after the data type and length, but before the CHARACTER SET clause,
and before column attributes such as DEFAULT, COLLATE, ON UPDATE,
SYSTEM VERSIONING, engine specific column attributes.

In the old reduction, the COMPRESSED clause was a column attribute.

New syntax:
  <varchar or text data type> <length> <compression> <character set> <column attributes>
  <varbinary or blob data type> <length> <compression> <column attributes>

New syntax examples:
  VARCHAR(1000) COMPRESSED CHARACTER SET latin1 DEFAULT ''
  BLOB COMPRESSED DEFAULT ''

Deprecate syntax examples:
  VARCHAR(1000) CHARACTER SET latin1 COMPRESSED DEFAULT ''
  TEXT          CHARACTER SET latin1 DEFAULT '' COMPRESSED
  VARBINARY(1000) DEFAULT '' COMPRESSED

As a side effect:
- COMPRESSED is not valid as an SP label name in SQL/PSM routines any more
  (but it's still valid as an SP label name in sql_mode=ORACLE)

- COMPRESSED is now allowed in combination with GENERATED ALWAYS AS:

  TEXT COMPRESSED GENERATED ALWAYS AS REPEAT('a',1000)

Do not check my_errno before it is set, check errno instead.
Also, do not check errno, if prior pread() did not fail.

Restore the detection of default charset in command line utilities.
It worked up to 10.1, but was broken by Connector/C.

Moved code for detection of default charset from sql-common/client.c
to mysys, and make command line utilities to use this code if charset
was not specified on the command line.

There was two separate problems:
- Aria pagecache didn't properly handle re-reading of blocks
  that have given errors before (this triggered an assert)
- temporary tables that where opened several times where
  not properly closed in ALTER, REPAIR or OPTIMIZE table

Other things
- Added a couple of asserts that will make it easier to
  find problems like this in the future.

Avoid unnecessary creation of named objects for invoking
mtr_buf_t::for_each_block_in_reverse().

Updated ma_test1 to reflect the change from MDEV-15458 where
ma_write() doesn't update current record position anymore.

Fixes also MDEV-17837

Problem was that we did not ignore warnings from virtual fields when
updated virtual fields for to-be-replaced row.

when copying the TREE, take into account that init_tree can
internally adjust tree->size_of_element

Closes #830

If the allocation of spider_table_sts_threads failed,
we would DBUG_RETURN(error_num) without having initialized
it earlier.

Pre-initialize error_num to HA_ERR_OUT_OF_MEM and remove
a lot of assignments that thus became redundant.

This error was introduced in 207594af
(Spider 3.3.13).

Problem:
=========
One of the purge thread access the corrupted page and tries to remove from
LRU list. In the mean time, other purge threads are waiting for same page
in buf_wait_for_read(). Assertion(buf_fix_count == 0) fails for the
purge thread which tries to remove the page from LRU list.

Solution:
========
- Set the page id as FIL_NULL to indicate the page is corrupted before
removing the block from LRU list. Acquire hash lock for the particular
page id and wait for the other threads to release buf_fix_count
for the block.

- Added the error check for btr_cur_open() in row_search_on_row_ref().

Before killing the server, ensure that the incomplete state of
the transaction will be made durable and will be applied and
rolled back on recovery, so that each time, roughly the same
amount of work will be done.

Remove DML statements after the recovery, and execute
CHECK TABLE instead.

Remove the test, because it easily fails with a result difference.
Analysis by Thirunarayanan Balathandayuthapani:

By default, innodb_encrypt_tables=0.
1) Test case creates 100 tables in innodb_encrypt_1.
2) creates another 100 unencrypted tables (encryption=off) in innodb_encrypt_2
3) creates another 100 encrypted tables (encryption=on) in innodb_encrypt_3
4) enabling innodb_encrypt_tables=1 and checking that only
100 encrypted tables exist. (already we have 100 in dictionary)
5) opening all tables again (no idea why)
6) After that, set innodb_encrypt_tables=0 and wait for 100 tables
to be decrypted (already we have 100 unencrypted tables)
7) dropping all databases

Sporadic failure happens because after step 4, it could encrypt the
normal table too, because innodb_encryption_threads=4.

This test was added in MDEV-9931, which was about InnoDB startup being
slow due to all .ibd files being opened. There have been a number of
later fixes to this problem. Currently the latest one is
commit cad56fba, in which some tests
(in particular the test innodb.alter_kill) could fail if all InnoDB
.ibd files are read during startup. That could make this test redundant.

Let us remove the test, because it is big, slow, unreliable, and
does not seem to reliably catch the problem that all files are being
read on InnoDB startup.

GCC 9.1.1 noticed that sd_notifyf() was always being invoked with
str=NULL argument for "%s". This code was added in
commit 2e814d47
but not mentioned in the commit comment.

The STATUS messages for systemd matter during startup and shutdown,
and should not be emitted during normal operation.

ib_senderrf(): Remove the potentially harmful sd_notifyf() calls.