This is also related to
MDEV-31348 Assertion `last_key_entry >= end_pos' failed in virtual bool
           JOIN_CACHE_HASHED::put_record()

Valgrind exposed a problem with the join_cache for hash joins:
=25636== Conditional jump or move depends on uninitialised value(s)
==25636== at 0xA8FF4E: JOIN_CACHE_HASHED::init_hash_table()
          (sql_join_cache.cc:2901)

The reason for this was that avg_record_length contained a random value
if one had used SET optimizer_switch='optimize_join_buffer_size=off'.

This causes either 'random size' memory to be allocated (up to
join_buffer_size) which can increase memory usage or, if avg_record_length
is less than the row size, memory overwrites in thd->mem_root, which is
bad.

Fixed by setting avg_record_length in JOIN_CACHE_HASHED::init()
before it's used.

There is no test case for MDEV-31893 as valgrind of join_cache_notasan
checks that.
I added a test case for MDEV-31348.

# Conflicts:
#	mysql-test/main/sp.result
#	mysql-test/main/sp.test

Remove redundant delete_explain_query() calls in

sp_instr_set::exec_core(), sp_instr_set_row_field::exec_core(),
sp_instr_set_row_field_by_name::exec_core().

These calls are made before the SP instruction's tables are
"closed" by close_thread_tables() call.

When we call close_thread_tables() after that, we no longer
can collect engine's counter variables, as they use the data
structures that are located in the Explain Data Structures.

Also, these delete_explain_query() calls are redundant, as
sp_lex_keeper::reset_lex_and_exec_core() has another
delete_explain_query() call, which is located in the right
location after the close_thread_tables() call.

The problem was that because there was no good indexes for the lineitem
table make_join_select() tried to do a last attempt to find a usable key
and called test_quick_select().
test_quick_select() found an index with fewer matching rows then every
before and that caused a problem in get_range_limit_read_cost(),
which assumes that 'best_rows' is the minium rows matched when all
conditions has been taken into account and thus smaller than rows found
in the range.
Fixed by adjusting best_rows to the least rows in any index after
test_quick_select() has been called.

The problem was a partitioned table had 0 rows, which caused a division by
zero at hash_join_fanout()
Fix: Do not call hash_join_fanout with 0 rows.

- InnoDB aborts when table is dropping the column. This is
caused by 5f09b53b (MDEV-31086).
While iterating the altered table fields, we fail to consider
the dropped columns.

when validating vcol's (default, check, etc) in ALTER TABLE
vcol_info->flags are modified in place. This means that if ALTER TABLE
fails for any reason we need to restore them to their original values.

(mroonga was freeing the memory on ::reset() but not on ::close())