This removes the test combination
rocksdb_rpl.mdev12179 'innodb,row,row-write-committed-slave-gtid-optimized'
for which the server failed to start due to the invalid parameter
slave_gtid_info=optimized.

This was broken in 5173e396

fts_sync(): Remove the constant parameter has_dict=false.

fts_sync_table(): Remove the constant parameter has_dict=false,
and the redundant parameter unlock_cache = !wait.
Make wait=true the default parameter.

An #include was forgotten in b6ac6738

PROBLEM
-------

Index defined on a virtual column whose base column was in a fk
relation was not getting updated. This is because while getting
the updated field information from the update vector of the parent
table we were comparing the column number of the base column (for
virtual column) in child table with the associated column number
in the parent table. There was a mismatch in this column number
because of which this update field information was skipped and
subsequently index was not getting updated.

FIX

Fixing post push test issues.

Recorded the result files for following:
rpl_stm_drop_create_temp_table.result
rpl_mixed_drop_create_temp_table.result.

The function pointer ut_timer() was only used by the
InnoDB defragmenting thread. Let InnoDB use a single monotonic
high-precision timer, my_interval_timer() [in nanoseconds],
occasionally wrapped by microsecond_interval_timer().

srv_defragment_interval: Change from "timer" units to nanoseconds.

This concludes the InnoDB time function cleanup that was
motivated by MDEV-14154. Only ut_time_ms() will remain for now,
wrapping my_interval_timer().

MDEV-5589 commit set up a policy to skip DROP TEMPORARY TABLE binary logging
in case the target table has not been "CREATEed" in binlog (no CREATE
Query-log-event was logged into the binary log).

It turns out that

1. the rule did not cover non-existing table DROPped with IF-EXISTS clause.
   The logged-create knowledge for the non-existing one does not even need
   MDEV-5589 patch, and

2. connection close disobeys it to trigger automatic DROP-IF-EXISTS
   binlogging.

Either 1 or 2 or even both is/are also responsible for unexpected binlog
records observed in MDEV-17863, actually rendering a referred
@@global.read_only irrelevant as far as the described stored procedure
definition *and* the ROW binlog-format are concerned.

The FTS optimizer thread made a false assumption that time(NULL)
is monotonic. The system clock can be adjusted to the past,
for example if the hardware clock was drifting to the future,
and it was adjusted by NTP.

fts_slot_t::interval_time: Replace with the constant
FTS_OPTIMIZE_INTERVAL_IN_SECS.

fts_slot_t::last_run, fts_slot_t::completed: Clarify the
documentation.

fts_optimize_get_time_limit(): Remove a type cast, and
add a FIXME comment about domain mismatch.

fts_optimize_compact(), fts_optimize_words(): Limit the time
also when the current time has been moved to the past.

fts_optimize_table_bk(): Check for wrap-around.

fts_optimize_how_many(): Check for wrap-around, and remove the
failing assertions.

fts_is_sync_needed(): Remove a redundant call to time(NULL).

lock_t::requested_time: Document what the field is used for.

lock_t::wait_time: Document that the field is only used for
diagnostics and may be garbage if the system time is being adjusted.

srv_slot_t::suspend_time: Document that this is duplicating
trx_lock_t::wait_started.

lock_table_print(), lock_rec_print(): Declare in static scope.
Add a parameter for the current time.

lock_deadlock_check_and_resolve(), lock_deadlock_lock_print(),
lock_deadlock_joining_trx_print():
Add a parameter for the current time.

srv_slot_t::suspend_time, os_aio_slot_t::reservation_time,
sync_cell_t::reservation_time: Explain what could happen
if the system time has is being adjusted.

fts_sync_t::start_time: Document that the field is mostly unused.

This affects the function has_higher_priority() for internal or
recovered transactions.

Replace ut_usectime() with my_interval_timer(),
which is equivalent, but monotonically counting nanoseconds
instead of counting the microseconds of real time.

os_event_wait_time_low(): Use my_hrtime() instead of ut_usectime().

FIXME: Set a clock attribute on the condition variable that allows
a monotonic clock to be chosen as the time base, so that the wait
is immune to adjustments of the system clock.

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

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