page_copy_rec_list_end_no_locks(): If needed, convert the records
to the flexible format. FIXME: Introduce a separate function for that.

btr_page_reorganize_low(): Allow format conversion.
FIXME: The conversion can fail due to out of space.
Handle that as well!

btr_cur_optimistic_insert(): If conversion is needed, invoke
btr_page_reorganize().

This aims to fix a bug in main.function_defaults_innodb,
but the test is now returning incorrect results
(garbage instead of NULL).

btr_page_reorganize_low(), btr_page_empty(): Create the page in the
flexible format if needed.

page_copy_rec_list_end_no_locks(): Adjust for dual-format tables.
FIXME: It may still be necessary to support conversion. Perhaps
the caller should invoke btr_page_reorganize_low() to do that.

MDEV-17432 Assertion `lock_trx_has_sys_table_locks(trx) == 0' failed upon ALTER TABLE .. ADD FOREIGN KEY

- Fixed innodb.table_flags test case in release build.

MDEV-17432 Assertion `lock_trx_has_sys_table_locks(trx) == 0' failed upon ALTER TABLE .. ADD FOREIGN KEY

- This is a regression of commit b26e603a. While dropping
the incompletely created table, InnoDB shouldn't consider that operation as non-atomic one.

When the with clause of a query contains a recursive CTE that is not used
then processing of EXPLAIN for this query does not require optimization
of the unit specifying this CTE. In this case if 'derived' is the
TABLE_LIST object created for this CTE then derived->derived_result is NULL
and any assignment to derived->derived_result->table causes a crash.
After fixing this problem in the code of st_select_lex_unit::prepare()
EXPLAIN for such a query worked without crashes. Yet an execution
plan for the recursive CTE appeared there. The cause of this problem was
an incorrect condition used in JOIN::save_explain_data_intern() that
determined whether CTE was to be optimized or not. A similar condition was
used in select_describe() and this patch has corrected it as well.

rec_get_n_fields(): Add the parameter 'comp' for specifying the format.

rec_offs_make_valid(): Consistently use rec_offs_comp(offsets).

Remove unnecessary #include.

Remove references to UNIV_MATERIALIZE, UNIV_INLINE_ORIGINAL, UNIV_NONINL
that are never defined.

FIXME: fix crashes in innodb.instant_alter_null, main.function_defaults_innodb

In 10.3, rec_is_metadata() takes a pointer, while in 10.4 it
takes a reference as a parameter. I ported this patch from
10.4 to 10.3, and then only ran a release build, not debug build.

The special flag REC_INFO_MIN_REC_FLAG used to be only set on the
first record in the leftmost node pointer page of each level of the tree.
It was never set on leaf pages.

MDEV-11369 Instant ADD COLUMN in MariaDB Server 10.3 repurposed the flag
to identify a hidden metadata record, which is stored in the first record
on the leftmost leaf page.

If the adaptive hash index points to records in the leftmost leaf page
after instant ALTER TABLE, we would have such a metadata record in the
table, an assertion could fail when trying to validate the index record.
In a release build, we might wrongly qualify the hidden metadata record
and thus return garbage results.

cmp_dtuple_rec_with_match_bytes(): If the REC_INFO_MIN_REC_FLAG is
set on the record, assert that this is the first record on the
leftmost page and that the record is a metadata record, and finally
return 1, because by definition, anything is greater than the
minimum record.

Also, related to MDEV-15522, MDEV-17304, MDEV-17835,
remove the Galera xtrabackup tests, because xtrabackup never worked
with MariaDB Server 10.3 due to InnoDB redo log format changes.

Disable tests that do not yet pass.