Skip tests which expectedly fail when Aria is not used for temporary tables

Commit ff88e4bb broke the Windows build.
Clean up one more redundant #include to fix it.

lock_discard_page(): Traverse and discard the B-tree record locks
only if they exist. Else, discard the R-tree (spatial) index locks.

Compare against the correct constant 0. NOT_KILLED belongs to
enum killed_state, while THD_IS_NOT_KILLED is what we want.

THD::close_temporary_tables(): Revert the change.

ha_innobase::delete_table(): Move the work-around inside
a debug assertion, and check thd_kill_level() instead of thd_killed(),
because the latter would not hold for KILL_CONNECTION.

For prepare statemtent/stored procedures we rollback the items to original
ones after prepare execution in the function reinit_stmt_before_use.
This rollback is done for group by, order by clauses but is not done for
the window specification containing the order by and partition by clause of the
window function.

MDEV-17726 Assertion `sqlcom != SQLCOM_TRUNCATE' failed in ha_innobase::delete_table after truncating temporary table

THD::close_temporary_tables(): Assign lex->sql_command so that
the debug assertion will not fail in ha_innobase::delete_table().

Alternatively, we could ensure that thd_killed() holds inside
ha_innobase::delete_table().

There should be no impact for the non-debug build. The thd_sql_command()
inside ha_innobase::delete_table() only affects the treatment of
persistent FOREIGN KEY metadata. There is no persistent metadata
nor foreign key constraints for temporary tables.

No test case was added, because the failure is nondeterministic.

The fix for "MDEV-17698 MEMORY engine performance regression"
previously fixed this problem.

- Adding the test for MDEV-17724
- Re-recording wrong results for tests:
  * engines/iuds/r/insert_number
  * engines/iuds/r/update_delete_number
  which started to fail since MDEV-17698

Also, backporting a part of:
  MDEV-11485 Split Item_func_between::val_int() into virtual methods in Type_handler
for easier merge to 10.3.

MDEV-16217: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date

- clean up DEFAULT() to work only with default value and correctly print
  itself.
- fix of DBUG_ASSERT about fields read/write
- fix of field marking for write based really on the thd->mark_used_columns flag

Produce syntax error when '{...]'.

MDEV-12575: Server crash in AGGR_OP::put_record or in JOIN_CACHE::free or Invalid write in JOIN::make_aggr_tables_info

During the optimize state of a query, we come know that the result set
would atmost contain one row, then for such a query we don't need
to compute GROUP BY, ORDER BY and DISTINCT.

MDEV-16174 Assertion `0' failed in Type_handler_string_result::make_sort_key(uchar*, Item*, const SORT_FIELD_ATTR*, Sort_param*)

maybe_null should be always set to TRUE in
Item_func_json_array_append::fix_length_and_dec()

           Item_direct_view_ref::derived_field_transformer_for_where
           upon updating a view

The condition pushed into a materialized derived / view mast be adjusted
for the new context: its column references must be substituted for
references to the columns of the underlying tables if the condition
is pushed into WHERE. The substitution is performed by the 'transform'
method. If the materialized derived is used in a mergeable view then
the references to the columns of the view are represented by
Item_direct_view_ref objects. The transform method first processes
the item wrapped in such an object and only after this it transforms
the object itself.
The transformation procedure of an Item_direct_view_ref object has
to know whether the item it wraps has been substituted. If so the
procedure does not have to do anything. In the code before this patch
it was not possible for the transformation procedure used by an
Item_direct_view_ref object to find out whether a substitution for
the wrapped item had happened.

The test innodb.log_file_name_debug failed to ensure that
the bogus redo log record that its debug injection emitted
would be consumed by a redo log checkpoint before running a
subsequent test, which could perform crash recovery.

Add an extra shutdown to ensure that a redo log checkpoint is
generated. In this way, the following will succeed:

./mtr --no-reorder innodb.log_file_name_debug innodb.read_only_recovery

This bug in the code of the function With_element::check_unrestricted_recursive()
could force a recursive CTE to be executed in a non-standard compliant mode
in which recursive UNION ALL could lead to an infinite execution. This
problem could occur only in the case when this CTE was used by another
recursive CTE at least twice.

There was a failure in rpl_delayed_slave after recent MDEV-14528 commit.
The parallel applier should not set its
Relay_log::last_master_timestamp from Format-descriptor log event.
The latter may reflect a deep past so Seconds-behind-master will be
computed through it and displayed all time while the first possibly
"slow" group of events is executed.

The main MDEV-14528 is refined, rpl_delayed_slave now passes also
in the parallel mode.

MDEV-11167: InnoDB: Warning: using a partial-field key prefix in search, results in assertion failure or "Can't find record" error

Fix ha_rnd_init() argument (we do not doing scan but use rnd_pos)

Fix is not to use blocking socket IO during SSL handshake.
With non-blocking socket IO, threadpool is able to utilize the wait
notification callbacks, that vio_io_wait() is calling whenever
socket would block.

When replicated events are from Master unaware of MariaDB GTID their handling by
the Parallel slave misses Seconds_Behind_Master updating.

In the bug condition the Show-Slave-Status' field remains unchanged.

Because in such case event execution is sequential the bug
is fixed with deploying the same logics as in the explicit single-threaded mode
with is to set

  Relay_log_event::last_master_timestamp

member early at the end of event reading from the relay log.