Remove .delta file after it was successfully applied

This incorrect alignment can later lead to memcpy over buffer boundaries,
and to a crash.

Fix incremental prepare to change file size while applying
delta file, if delta file contains page 0 with the new size.

Change fil_space_extend_must_retry() to use this function.

not just for creating new files.

Use os_file_set_size() in fil_space_extend_must_retry()

This is regression caused by patch of mdev-10767.

1st problem :- mktmp is invoked without '-t' or specifing tmp directory.
2nd problem :- Since eval_log_error redirect stderr to stdout  '2>' will
return nothing. and hence $wr_logfile will be empty.

Patch Credit:- Andrii Nikitin

btr_cur_pessimistic_delete(): Discard a possible record lock also in
the case when the record was the only one in the page. Failure to
do this would corrupt the record lock data structures in a partial
rollback (ROLLBACK TO SAVEPOINT or rolling back a row operation due
to some error, such as a duplicate key in a unique secondary index).

Patch contibuted by Gordon Fisher. Thank you for your contribution!

After review cleanup.

fix some old bad merge

avoid a function call for a commonly used one-liner.
followup for 0627929f

remove copy-pasted code, fix meaningless comparison.
followup for ea2162b6

Problem:- This crash happens because of thd = NULL , and while checking
for wsrep_on , we no longer check for thd != NULL (MDEV-7955). So this
problem is regression of MDEV-7955. However this patch not only solves
this regression , It solves all regression caused by MDEV-7955 patch.

To get all possible cases when thd can be null , assert(thd)/
assert(trx->mysql_thd) is place just before all wsrep_on and innodb test
suite is run. And the assert which caused failure are removed with a physical
check for thd != NULL. Rest assert are removed. Hopefully this method will
remove all current/potential regression of MDEV-7955.

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.

log_group_read_log_seg(): Only display the message during recovery,
not during normal operation. When the XtraDB configuration parameter
innodb_log_archive is set, this function will be called during
normal operation.

don't do it via MYSQL_TIME, that conversion is lossy
around DST change dates.

Implement a special Copy_field method for timestamps, that copies
timestamps without converting them to MYSQL_TIME (the conversion
is lossy around DST change dates).

libmariadbclient_18 version nodes, specially for debian builds

followup for 378beed0 - only count WARN_LEVEL_ERROR,
not warnings or notes.

tabtyp was defined under ODBC_SUPPORT, but used
outside of it too (under JDBC_SUPPORT).

don't prepare for checking view's CHECK OPTION, if
there is no CHECK OPTION in the first place.

Binlog_background_thread does not make a call to set_time(), And when
we call binlog_checkpoint_log_event->write() , we write the wrong timestamp.
In this patch we correct this by calling thd->set_time().

Problem:- To create file in /tmp dir mysqld require permission initrc_tmp_t.
And mysqld does not have his permission.

Solution:- Instead of giving mysqld permission of initrc_tmp_t , we redirected
log to file in /tmp dir through shell. I also removed a earlier workarround
in mysqld_safe.sh , which create tmp log file in datadir.

MDEV-13290: Assertion Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' or `! is_set()' failed

followup for 97c2a735 - don't use thd->is_error(),
the error could've been set before TABLE_LIST::cleanup_items.
Use the error handler to count errors.

This fixes rpl.rpl_row_binlog_max_cache_size - it was failing when
ER_STMT_CACHE_FULL happened duing multi-table update. Because
multi_update::abort_result_set() calls do_updates() to update
as much as possible, so one cannot rely on thd->is_error() after that.