Support index condition pushdown within partitioned tables.
- ha_partition will pass the pushed index condition into all of the used
  partitions.
  - We require that all of the partitions to handle the pushed index
    condition in the same way.
- When using ICP, one may read rows (e.g. call h->index_read_map(buf, ...)
  only to buf= table->record[0], for two reasons:
  * Pushed index condition's Item_field objects point into record[0]
  * InnoDB requires this: it calls offset() which assumes record[0].
  So, when using ICP, ha_partition will read partition records to
  table->record[0] and then will copy record away if it needs it to be
  elsewhere.

Part#2, variant 2: Make the printed r_ values in JSON output consistent.
After this patch, ANALYZE output has:

- r_index_rows (NEW) - Observed number of rows before ICP or Rowid Filtering
  checks. This is a per-scan average. like r_rows and "rows" are.

- r_rows (AS BEFORE) - Observed number of rows after ICP and Rowid Filtering.

- r_icp_filtered (NEW) - Observed selectivity of ICP condition.

- (AS BEFORE) observed selectivity of Rowid Filter is in
  $.rowid_filter.r_selectivity_pct

- r_total_filtered - Observed combined selectivity: fraction of rows left
  after applying ICP condition, Rowid Filter, and attached_condition.
  This is now comparable with "filtered" and is printed right after it.

- r_filtered (AS BEFORE) - Observed selectivity of "attached_condition".

Tabular ANALYZE output is not changed. Note that JSON's r_filtered and
r_rows have the same meanings as before and have the same meaning as in
tabular output.

(Based on the original patch by Jason Cu)

Part #1:
- Add ha_handler_stats::{icp_attempts,icp_match}, make
  handler_index_cond_check() increment them.
- ANALYZE FORMAT=JSON now prints r_icp_filtered based on these counters.

AIX compilation failed, because glibc's non-standard extension to
`struct tm` were used - additional members tm_gmtoff and tm_zone.

The patch fixes it by adding corresponding compile-time check.

Additionally, for the calculation of GMT offset on AIX, a portable
variant of timegm() was required.Implementation here is inspired by
SergeyD's answer on Stackoverflow :
https://stackoverflow.com/questions/16647819/timegm-cross-platform

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

This patch adds PACKAGE support with SQL/PSM dialect for sql_mode=DEFAULT:

- CREATE PACKAGE
- DROP PACKAGE
- CREATE PACKAGE BODY
- DROP PACKAGE BODY
- Package function and procedure invocation from outside of the package:
    -- using two step identifiers
    SELECT pkg.f1();
    CALL pkg.p1()

    -- using three step identifiers
    SELECT db.pkg.f1();
    CALL db.pkg.p1();

This is a non-standard MariaDB extension.

However, later this code can be used to implement
the SQL Standard and DB2 dialects of CREATE MODULE.

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.

This file isn't used by client or server. Its
functionality is purely in the generation of *.sys
files.

As such omit from packaging and save ~1MB.

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)