Upon investigation, decided this to be a compiler bug
(happens with new compiler, on code that did not change for the last 15 years)

Fixed by de-optimizing single function remove_key(), using MSVC pragma

This fixes up commit d22c8cae

The previous threads locked need to be released too.

This occurs if the initialization of any of the non-first
mutex/conditition variables errors occurs.

Fix a bug of unreleased lock ctrl_mutex in the method create_worker_threads

added summary/description per package.

When transaction creates or drops temporary tables and afterward its statement
faces an error even the transactional table statement's cached ROW
format events get involved into binlog and are visible after the transaction's commit.

Fixed with proper analysis of whether the errored-out statement needs
to be rolled back in binlog.
For instance a fact of already cached CREATE or DROP for temporary
tables by previous statements alone
does not cause to retain the being errored-out statement events in the
cache.
Conversely, if the statement creates or drops a temporary table
itself it can't be rolled back - this rule remains.

old ftp.pcre.org is apparently down,
www.pcre.org says to use github as the primary download location

This reverts commit 5d6f3ceb.

Drop and add same key is considered rename (look ALTER_RENAME_INDEX in
fill_alter_inplace_info()). But in this case order of keys may be
changed, because mysql_prepare_alter_table() yet does not know about
rename and treats 2 operations: drop and add.

In that case we disable inplace algorithm for such engines as Memory,
MyISAM and Aria with ALTER_INDEX_ORDER flag. These engines have no
specialized check_if_supported_inplace_alter() and default
handler::check_if_supported_inplace_alter() sees an unknown flag and
returns HA_ALTER_INPLACE_NOT_SUPPORTED.

ha_innobase::check_if_supported_inplace_alter() works differently and
inplace is not disabled (with the help of modified
INNOBASE_INPLACE_IGNORE). add_drop_v_cols fork was also tweaked as it
wrongly failed with MSG_UNSUPPORTED_ALTER_ONLINE_ON_VIRTUAL_COLUMN
when it seen ALTER_INDEX_ORDER.

No-op operation must be still no-op no matter of ALTER_INDEX_ORDER
presence, so we tweek its condition as well.

mysql_prepare_create_table() does my_qsort(sort_keys) on key
info. This sorting is indeterministic: a table is created with one
order and inplace alter may overwrite frm with another order. Since
inplace alter does nothing about key info for MyISAM/Aria storage
engines this results in discrepancy between frm and storage engine key
definitions.

The fix avoids the sorting of keys when no new keys added by ALTER
(and this is ok for MyISAM/Aria since it cannot add new keys inplace).

There is a case when implicit primary key may be changed when removing
NOT NULL from the part of unique key. In that case we update
modified_primary_key which is then used to not skip key sorting.

According to is_candidate_key() there is no other cases when primary
key may be changed implicitly.

Notes:

mi_keydef_write()/mi_keyseg_write() are used only in mi_create(). They
should be used in ha_inplace_alter_table() as well.

Aria corruption detection is unimplemented: maria_check_definition()
is never used!

MySQL 8.0 has this bug as well as of 8.0.26.

versioning_fields flag indicates that any columns were specified WITH
SYSTEM VERSIONING. In that case we imply WITH SYSTEM VERSIONING for
the whole table and WITHOUT SYSTEM VERSIONING for the other columns.

When restoring lastinx last_key.keyinfo must be updated as well. The
good example is in _ma_check_index().

The point of failure is extra(HA_EXTRA_NO_KEYREAD) in
ha_maria::get_auto_increment():

  1. extra(HA_EXTRA_KEYREAD) saves lastinx;
  2. maria_rkey() changes index, so the lastinx and last_key.keyinfo;
  3. extra(HA_EXTRA_NO_KEYREAD) restores lastinx but not
     last_key.keyinfo.

So we have discrepancy between lastinx and last_key.keyinfo after 3.

* Fix error handling NULL-pointer reference
* Add mtr-suppression on galera_ssl_upgrade