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

In dict_index_t::clear(), InnoDB frees all the page except root page.
root page leaf segment has reset and does reinitialize again.
t in fseg_create(), we do have the assumption that only
FIL_PAGE_TYPE_TRX_SYS or FIL_PAGE_TYPE_TRX_SYS page should
be re-created for non-full-crc32 format. This assumption is wrong
in case of rollback of bulk insert operation.

MDEV-27006 Assertion `!lock_trx_has_sys_table_locks(trx)' failed in dberr_t row_discard_tablespace_for_mysql(dict_table_t*, trx_t*)

- InnoDB import operation fails when it tries to unlock data
dictionary lock before releasing the lock on system tables.

The debug assertion that was added in
commit 9b967c4c
tripped Valgrind and MemorySanitizer.

buf_block_init(): Assert that block->page.hash was zero-initialized.

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.

MDEV-26956 LeakSanitizer/Valgrind errors in trx_mod_table_time_t::start_bulk_insert upon adding system versioning

 InnoDB fails to apply buffered insert operation for
'mysql/transaction_registry' table during system versioning DDL.
To avoid this, DDL calls extra(HA_EXTRA_IGNORE_INSERT) to
inform the InnoDB for applying the buffered insert operation.

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.

In commit c091a0bc we removed
the use of the HASH_ macros for inserting into
buf_pool.page_hash, or accessing buf_page_t::hash.

However, the binary buddy allocator for block->page.zip.data would
still use the HASH_ macros. HASH_INSERT and not HASH_DELETE would reset
the next-block pointer to the null pointer. Our replacement of
HASH_DELETE() will reset the next-block pointer, and the replacement of
HASH_INSERT() assumes that the pointer is the null pointer.

buf_LRU_block_free_non_file_page(): Assert that the next-block pointer
is the null pointer.

buf_buddy_block_free(): Reset the pointer before invoking
buf_LRU_block_free_non_file_page(). Without this, the added
assertion would fail in the test encryption.innochecksum.