row_upd_changes_field_size_or_external(): Revert some unnecessary
changes, and assert that the update vector does not contain the
magic value UNIV_SQL_DEFAULT.

row_upd_rec_in_place(): Remove a redundant assertion.
rec_set_nth_field() already asserts the same.

row_upd_build_sec_rec_difference_binary(): Assert that there are
no default values in a secondary index tuple.

The ALGORITHM=INPLACE interface is not accessible to temporary tables.
Therefore, instant ADD COLUMN cannot be used either.

dict_table_t::is_temporary(): New predicate.

dict_table_is_temporary(): Define as a wrapper macro.

In the temporary file that is applied by row_log_table_apply(),
we must identify whether the records contain the extra header for
instantly added columns. For now, we will allocate an additional byte
for this for ROW_T_INSERT and ROW_T_UPDATE records when the source table
has been subject to instant ADD COLUMN. The ROW_T_DELETE records are
fine, as they will be converted and will only contain 'core' columns
(PRIMARY KEY and some system columns) that are converted from dtuple_t.

rec_get_converted_size_temp(), rec_init_offsets_temp(),
rec_convert_dtuple_to_temp(): Add the parameter 'status'.

rec_set_n_add_field(): Simplify the interface to resemble
rec_get_n_add_field().

rec_init_offsets_comp_ordinary(): Handle the new rec_leaf_format
constant REC_LEAF_TEMP_COLUMNS_ADDED.

rec_get_converted_size_comp_prefix_low(),
rec_convert_dtuple_to_rec_comp(): Handle
index->is_instant() for both temp and !temp.

Ensure that no adaptive hash index exists for any system tables,
so that the blocked TRUNCATE TABLE t1 will not block the concurrent
TRUNCATE TABLE t2.

Ensure that no adaptive hash index exists for any system tables,
so that the blocked TRUNCATE TABLE t1 will not block the concurrent
TRUNCATE TABLE t2.

Made a few links in README.md secure (https).

This bug is a regression caused by the code refactoring in
commit f5a833c3. It was not present
in any release of the MariaDB server. The bug affects table-rebuilding
ALTER TABLE when the source table is in ROW_FORMAT=REDUNDANT and
contains no virtual columns.

row_log_table_low_redundant(): Log virtual column data only if
virtual columns are present.

In TRUNCATE TABLE, clear the 'instant' status of a table. TODO: Do the same when the table becomes empty

dict_col_t::remove_instant(): Remove the instantness of a column.

dict_index_t::remove_instant(): Remove the instantness of a clustered index.

This bug is a regression caused by the code refactoring in
commit f5a833c3. It was not present
in any release of the MariaDB server. The bug affects table-rebuilding
ALTER TABLE when the source table is in ROW_FORMAT=REDUNDANT and
contains no virtual columns.

row_log_table_low_redundant(): Log virtual column data only if
virtual columns are present.

The issue was that r_loops, r_rows and r_filtered in ANALYZE FORMAT= JSON were not
calculated for the table on which we were performing the MRR scan in the BKA join
Fixed this by adding respective counter in the JOIN_TAB_SCAN_MRR::open and JOIN_TAB_SCAN_MRR::next

The problem is there is an overflow for the key_file_length.
Added the maximum limit for the key_file_length

The ALTER TABLE…IMPORT TABLESPACE adjustment code that was introduced by
WL#5522 in MySQL 5.6 is incorrectly invoking rec_get_status() on a
ROW_FORMAT=REDUNDANT record to determine if a record is a leaf page record.
The function rec_get_status(rec) is only to be called on
ROW_FORMAT=COMPACT, DYNAMIC or COMPRESSED records.

The ALTER TABLE…IMPORT TABLESPACE adjustment code that was introduced by
WL#5522 in MySQL 5.6 is incorrectly invoking rec_get_status() on a
ROW_FORMAT=REDUNDANT record to determine if a record is a leaf page record.
The function rec_get_status(rec) is only to be called on
ROW_FORMAT=COMPACT, DYNAMIC or COMPRESSED records.

Revert any changes that are not needed any more.

Most of the code submitted by Vinchen has been refactored so far.
The redo log format changes are as they were submitted by Vinchen.

FIXME: On rollback, convert the record to "old" format if the values
match the 'default row' ones. There should be no need to write any
new BLOBs during rollback. If we created new BLOBs during rollback,
crash recovery could become very tricky.

TODO: Review the changes to row0upd.cc, row0umod.cc. For new inserts
and updates, if the suffix of instantly added columns match the
'default row', we can omit those fields from the clustered index
record. If a non-default value is assigned to the last column, then
all columns will have to be materialized.

TODO: Implement update-in-place of the 'default row' record
(for performing instant ADD COLUMN after instant ADD COLUMN).

TODO: Implement and test rollback of the 'default row' record.

TODO: Test crash recovery. Ensure that the ADD COLUMN operation
is being rolled back if the server is killed during it. Also test
crash recovery of DML operations on tables that were subject to
instant ADD COLUMN, using all supported ROW_FORMAT (REDUNDANT,
COMPACT, DYNAMIC).

3-argument form of DATE_FORMAT