Derived table creation code would call Field::make_new_field() which would
memcpy the Field object from the source table, including Field::read_stats.

But the temp. table as a whole had table->stats_is_read=false. Which was
correct but not consistent with Field::read_stats and caused an assertion.

Fixed by making sure that Field::read_stats=NULL for fields in the new
temporary (i.e. work) tables.

The problem, introduced in patch for MDEV-26301:

When check_join_cache_usage() decides not to use join buffer, it must
adjust the access method accordingly. For BNL-H joins this means switching
from pseudo-"ref access"(with index=MAX_KEY) to some other access method.

Failing to do this will cause assertions down the line when code that is
not aware of BNL-H will try to initialize index use for ref access with
index=MAX_KEY.

The fix is to follow the regular code path to disable the join buffer for
the join_tab ("goto no_join_cache") instead of just returning from
check_join_cache_usage().

Do not try to decide merge/materialize for derived if it was already decided
(even if it is a view).

RocksDB (in a submodule) has to include <cstdint> to use uint64_t
but it doesn't. Until the submodule is upgraded, let's replace
problematic types with something that's available

select_insert::store_values() must reset
has_value_set bitmap before every row, just like mysql_insert() does.
because ON DUPLICATE KEY UPDATE and triggers modify it

Temporary fix to avoid the server crash.

Add Optimizer Trace printouts.

This patch optimizes the number of refills for the lateral derived table
to which a materialized derived table subject to split optimization is
is converted. This optimized number of refills is now considered as the
expected number of refills of the materialized derived table when searching
for the best possible splitting of the table.

(part 1 is in the previous commit)
to [ pass ] galera.MDEV-18832, galera.MDEV-27862

1. log_event.cc stuff should go into log_event_server.cc
2. the test's wait condition is textually different in 10.5, fixed.
3. pre-exec 'optimistic' global var value is correct for 10.5 indeed.