MDEV-33101 Server crashes when starting the server with innodb-force-recovery=6 and enabling the innodb_truncate_temporary_tablespace_now variable

The issue is introduced by "MDEV-28699: Shrink temporary tablespaces
without restart". SRV_FORCE_NO_LOG_REDO forces server to read only mode
and we don't initialize temporary tablespace in read only mode.

solution: innodb_truncate_temporary_tablespace_now should be no-op in
read only mode.

make_item_func_call_generic() should take `db_int`, not `db`

btr_pcur_move_to_next_page(): Add code that was wrongly deleted in
the merge commit 8c8bce05

Errors outputted as notes are weird, and when a user
cannot do anything about them, why output them at all.

Point taken, removed these, and left positive message
on initialization (from Marko).

Thanks Elena Stepanova.

mariadb-backup wasn't meant to have memory pressure
sensors so restrict the operation to SRV_OPERATIONAL_NORMAL
mode.

Reviewed by Daniel Black.

trx_purge_truncate_history(): If a fast shutdown has been initiated,
disregard innodb_undo_log_truncate=ON and return.

The previous patch for MDEV-10653 changes the rpl_parallel::workers_idle()
function to use Relay_log_info::last_inuse_relaylog to check for idle
workers. But the code was missing a NULL check. Also, there was one place
during SQL slave thread start which was missing mutex synchronisation when
updating inuse_relaylog.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

The error-injection inject_mdev8031 simulates a deadlock kill in a specific
place, by setting killed_for_retry to RETRY_KILL_KILLED directly. If a real
deadlock kill triggers at the same time, it is possible for the thread to
complete its transaction retry and set rgi_slave to NULL before the real
readlock kill can complete in the background. This will cause a segfault
due to null-pointer access.

Fix by changing the error injection to do a real background deadlock kill,
which ensures that the thread will wait for any pending background kills to
complete.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

Item::val_str() sets the Item::null_value flag, so call it before checking
the flag, not after.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>

trx_purge_truncate_history(): Release buf_pool.flush_list_mutex
and 'dummily' acquire and release buf_pool.mutex before starting
a rescan of buf_pool.flush_list, to ensure that
the buf_flush_page_cleaner thread (which may be holding buf_pool.mutex)
will be able to proceed.

This fixes up commit 5dbe7a8c (MDEV-32757).

Tested by: Axel Schwenke (on Ubuntu 18.04 and Ubuntu 20.04)
Reviewed by: Vladislav Lesin

This commit addresses the file leakage problem encountered with the mysql_upgrade --check-if-upgrade-is-needed command.

e.g. it could be

{"errors":["no handler for route \"mariadbtest/data/1\". route entry not found."]}

ASAN uses *a lot* more stack. use not_asan.inc for tests
that recursively put a lot of data on the stack

"InnoDB: The last skipped log record LSN X is not equal to page LSN Y"
is not an actionable message for the user, so it should be a note, not
a warning

to iterate over all status variables one should use
LOCK_all_status_vars not LOCK_status

this fixes sporadic mutex lock inversion in plugins.password_reuse_check:
* acl_cache->lock is taken over complex operations that might increment
  status counters (under LOCK_status).
* acl_cache->lock is needed to get the values of Acl% status variables
  when iterating over status variables

variable

Analysis:
Since the item is NULL, it's json value is NULL but we proceed to parse
it anyway.
Fix:
If json value is NULL, return NULL.

buf_read_ahead_linear(): Suppress a warning of comparing potentially
uninitialized FIL_PAGE_PREV and FIL_PAGE_NEXT fields.

it can be invoked with ms=0. In that case dict_stats_func is
invoked immediately, it calls dict_stats_process_entry_from_recalc_pool()
which at the end might try to call dict_stats_schedule() again to
queue another recalc. And it can happen that the first
dict_stats_schedule(0) call didn't release dict_stats_mutex yet,
so the second dict_stats_schedule() won't queue a recalc. And as a
result the table won't have its stats recalculated at all, not now,
not later.

This causes innodb.innodb_stats_auto_recalc to fail sporadically.

This commit doesn't fix it but makes it less likely to occur which happens
to be enough for the test to pass. Proper fix is coming soon.

use signal_ddl_recovery_done callback for that.

also make the server to call signal_ddl_recovery_done() when loading
plugins at run-time (so that plugins would't need to detect that
on their own)

trx_purge_truncate_history(): Release buf_pool.flush_list_mutex
before starting a rescan of buf_pool.flush_list, to ensure that
the buf_flush_page_cleaner thread (which may be holding buf_pool.mutex)
will be able to proceed.

This fixes up commit a0f02f74 (MDEV-32757).

Tested by: Axel Schwenke
Reviewed by: Vladislav Lesin

see also 4eca64e3

- InnoDB should write all zeros into a table and its indexes
statistics members when table is unreadable.

followup for ad796aaa

When making commits, the branches to target are not clearly defined in
public documentation, and frequently change. As the development branch
and the earliest maintained branches progress, it should be reflected in
CODING_STANDARDS.md.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services.