This was forgotten in the merge 0f83c887
because the test is disabled.

MDEV-19870 gcol.innodb_virtual_debug_purge doesn't fail if row_vers_old_has_index_entry gives wrong result

1) Whenever purge thread tries to remove the secondary virtual index
entry, purge thread acquires metadata lock for the table and release
dict_operation_lock. After that, it retries the secondary index
deletion if MDL acquired successfully.

2) Inside row_vers_old_has_index_entry(), Change the safe_to_purge
to unsafe_to_purge goto statement. So it can be more appropriate to
return true if it is unsafe_to_purge.

3) Previously, row_vers_old_has_index_entry() returns false if InnoDB
fetched the MDL on the table for the first time. This check(two cases)
should checked only during purge thread. In row_purge_poss_sec(), again
InnoDB checks whether the MDL fetched for the first time. If it is then
InnoDB retry the secondary index deletion logic. So in that case,
InnoDB have to clean up the memory used inside row_vers_old_has_index_entry()
and shouldn't care about return value.

Use microsecond_interval_timer()
or my_interval_timer() [in nanoseconds] instead.

This is motivated by PS-5221 in
percona/percona-server@2817c561fce9e20a83b13272ac45fd333467715d

The coarser-precision ut_time() will still refer to the
system clock, meaning that bad things can happen if the
real time clock is adjusted backwards.

Valgrind started supporting CRC32 instruction starting with version
3.6.1, released in 2011. Thus remove the fallback to software
implementation in case running under Valgrind.

There is one directly applicable change to InnoDB:
commit 739f5239 in the
5.5 branch will be merged before the next MariaDB releases.

Another potentially applicable change will be tracked
separately as MDEV-20126.

Thus, here we only update the InnoDB version number and do
not change anything else.

This is follow-up to d36c107a

This is a regression due to MDEV-16515 that affects some versions in
the MariaDB 10.1 server series starting with 10.1.35, and possibly
all versions starting with 10.2.17, 10.3.8, and 10.4.0.

The idea of MDEV-16515 is to allow DROP TABLE to be interrupted,
in case it was stuck due to some concurrent activity. We already
made some cases of internal DROP TABLE immune to kill in MDEV-18237,
MDEV-16647, MDEV-17470. We must include the cleanup of
CREATE TABLE...SELECT in the list of such internal DROP TABLE.

ha_innobase::delete_table(): Pass create_failed=true if the current
SQL statement is CREATE, so that the table will be dropped.

row_drop_table_for_mysql(): If create_failed=true, do not allow
the operation to be interrupted.

This is the race between DELETE and INSERT (or other any two operations accessing to the table).
What should happen in good case:
1. ALTER TABLE is issued. vc_templ->default_rec is initialized with temporary share's default_fields
2. temporary share is freed, but datadict is still there, with garbage in vc_templ->default_rec
3. DELETE is issued. It is first after ALTER TABLE finished.
4. ha_innobase::open() is called, ib_table->get_ref_count() should be one
5. we reinitialize vc_templ, so no garbage anymore

What actually happens:
3. DELETE is issued.
4. ha_innobase::open() is called and ib_table->get_ref_count() is 1
5. INSERT (or SELECT etc.) is issued in parallel
6. ha_innobase::open() is called and ib_table->get_ref_count() is 1
7. we check ib_table->get_ref_count()  and it is 2 in both threads when we want reinitialize vc_templ
8. garbage is there

Fix:
* Do not store pointers to SHARE memory in table dict, copy it instead.
* But then we don't need to refresh it each time when refcount=1.

The test for the wsrep_info plugin needs the same flexible wsrep version checking as the tests for Galera (continuation of MDEV-18565 task)

The test for the wsrep_info plugin needs the same flexible wsrep version checking as the tests for Galera (continuation of MDEV-18565 task)

Make it to work on Windows, too.

Rewrite the unportable sed/shell code in Perl.

Store REDZONE_SIZE poined bytes before every allocated chunk of memory

The embedded server does not HAVE_PSI_STAGE_INTERFACE.

row_merge_read_clustered_index(): fix one more place with buf and merge_buf[i]

The results are nondeterministic on MariaDB Server 10.1.

row_merge_read_clustered_index(): make buf always equals to merge_buf[i]

MDEV-20094 was filed for the unexpected result differences for the test
innodb.check_ibd_filesize.