The main idea of the Oracle fix is related to the limiting the atomicity of fts_sync_write_words().
This part of the fix wrongly assumes that the system clock is monotonic (never moving backwards):

ulint cache_lock_time = ut_time() - sync_start_time;

if (cache_lock_time > lock_threshold) {

Similar to our MDEV-14154 changes, in particular the one that removed bogus assertions, we should use something like this:

ulint interval = ulint(time(NULL) - start_time);

if (lint(interval) < 0 || interval > time_limit)) {

That is, we will time out if the time moved backwards.

Because time(NULL) may have a much lower overhead than my_interval_timer() or other monotonic clock sources and because the precision of one second suffices here, I think that we should stick to time(NULL).

Anyway, the main idea of the Oracle change is to extend the innodb_fatal_semaphore_wait_threshold (srv_fatal_semaphore_wait_threshold) if a fts_sync_table() operation from outside the optimizer thread is taking longer. That is, it will prevent the operation of the InnoDB built-in watchdog, instead of actually fixing the root cause of the problem.

To fix this issue, InnoDB should have multiple fts_optimize_threads to process the messages from the queue.
By using multiple fts_optimize_threads, InnoDB can reduce the cache size significantly and it can make
lesser wait time for DDL/dict_table_mem_free() for fts_optimize_remove_table().