fixes errors on rpm-*-debug builder

pass the pointer to thd->killed down to the json library,
check it while scanning,
use thd->check_killed() to generate the proper error message

preallocate the string in json_nice()
to avoid reallocs on every 1-character append()

that was permanently disabled in a merge mistake. also
* use auth_test_plugin to test dumping of plugins and user auth,
  as the original test intended
* s/USER/foobar/ to make a username searchable

The correct macro to detect the AMD64 ISA is _M_X64, not M_IX64.

This is the 10.6 version of
commit fb8fea34 (10.5).

Even though Apple Xcode is based on and similar to Clang,
it does not support the asm goto construct which was added
in commit 668a5f3d (MDEV-26720)
to work around a compiler deficiency that results in suboptimal
code being generated for IA-32 and AMD64.

We will disable this manual optimization if __APPLE_CC__ is defined.

Similar constructs are also used in sync/srw_lock.cc, but that code
is not used on Apple, because we have not implemented a Linux futex
compatible interface on Apple macOS.

Thanks to Valerii Kravchuk for reporting and testing this.

Most of this was likely already fixed by MDEV-27017.
On one implementation of the AMD64 ISA, the test
innodb_fts.concurrent_insert would still occasionally hang,
with both dict_sys_t::evict_table_LRU() and
dict_index_set_merge_threshold() waiting in dict_sys_t::lock()
several threads waiting in dict_sys_t::freeze(),
no thread holding exclusive dict_sys.latch and also no thread
in the stack traces apparently holding any dict_sys.latch,
even though dict_sys.latch_readers == 1.

To prevent this scenario, we will remove the dict_sys.latch
acquisition from dict_index_set_merge_threshold(). It is actually
not needed, because dict_sys.sys_indexes will not change after
InnoDB startup. The SYS_INDEXES leaf page will be sufficiently
protected by the page latch.

There potentially is a bug in the srw_lock implementation,
which will have to be investigated further.

The test innodb.log_file_size would occasionally fail with
an assertion failure !buf_pool.any_io_pending(). Let us wait
for the page cleaner thread to become idle already in
srv_prepare_to_delete_redo_log_file(), like we used to.

A query in form

  SELECT DISTINCT expr_that_is_inferred_to_be_const LIMIT 0 OFFSET n

produces one row when it should produce none. The issue was in
JOIN_TAB::remove_duplicates() in the piece of logic that tried to
avoid duplicate removal for such cases but didn't account for possible
"LIMIT 0".

Fixed by making Select_limit_counters::set_limit() change OFFSET to 0
when LIMIT is 0.

The code was backported from 10.6 bd03c0e5
commit. See that commit message for details.

Apart from the above commit trx_lock_t::wait_trx was also backported from
MDEV-24738. trx_lock_t::wait_trx is protected with lock_sys.wait_mutex
in 10.6, but that mutex was implemented only in MDEV-24789. As there is no
need to backport MDEV-24789 for MDEV-27025,
trx_lock_t::wait_trx is protected with the same mutexes as
trx_lock_t::wait_lock.

This fix should not break innodb-lock-schedule-algorithm=VATS. This
algorithm uses an Eldest-Transaction-First (ETF) heuristic, which prefers
older transactions over new ones. In this fix we just insert granted lock
just before the last granted lock of the same transaction, what does not
change transactions execution order.

The changes in lock_rec_create_low() should not break Galera Cluster,
there is a big "if" branch for WSREP. This branch is necessary to provide
the correct transactions execution order, and should not be changed for
the current bug fix.

When lock is checked for conflict, ignore other locks on the record if
they wait for the requesting transaction.

lock_rec_has_to_wait_in_queue() iterates not all locks for
the page, but only the locks located before the waiting lock in the
queue. So there is some invariant - any lock in the queue can wait only
lock which is located before the waiting lock in the queue.

In the case when conflicting lock waits for the transaction of
requesting lock, we need to place the requesting lock before the waiting
lock in the queue to preserve the invariant. That is why we are looking
for the first waiting for requesting transation lock and place the new
lock just after the last granted requesting transaction lock before the
first waiting for requesting transaction lock.

Example:

trx1 waiting lock, trx1 granted lock, ..., trx2 lock - waiting for trx1
place new lock here -----------------^

There are also implicit locks which are lazily converted to explicit
ones, and we need to place the newly created explicit lock to the correct
place in a queue. All explicit locks converted from implicit ones are
placed just after the last non-waiting lock of the same transaction before
the first waiting for the transaction lock.

Code review and cleanup was made by Marko Mäkelä.

In commit 4c3ad244 (MDEV-27416)
an unnecessarily strict wait condition was introduced in the
function buf_flush_wait(). Most callers actually only care that
the pages have been flushed, not that a checkpoint has completed.

Only in the buf_flush_sync() call for log resizing, we might care
about the log checkpoint. But, in fact,
srv_prepare_to_delete_redo_log_file() is explicitly disabling
checkpoints. So, we can simply remove the unnecessary wait loop.

Thanks to Krunal Bauskar for reporting this performance regression
that we failed to repeat in our testing.

bump maturity to beta

MDEV-25373 DROP TABLE doesn't raise error while dropping non-existing table in MariaDB 10.5.9 when OQGraph SE is loaded to the server

don't auto-succeed every DROP TABLE

buf_pool_t::realloc(): Invoke page_cleaner_wakeup()
if buf_LRU_get_free_only() returns a null pointer.

Ever since commit 7b1252c0 (MDEV-24278)
the page cleaner would remain in untimed sleep, expecting explicit
calls to buf_pool_t::page_cleaner_wakeup() when the ratio of dirty pages
could change.

Failure to wake up the page cleaner will cause all page writes to be
initiated by buf_flush_LRU_list_batch(). That might work too,
provided that the buffer pool size is at least BUF_LRU_MIN_LEN (256)
pages, but it would not advance the log checkpoint.

In commit c5fd9aa5 (MDEV-25919)
we prevented the function dict_stats_save_index_stat()
from being called in read-only mode in dict_stats_save(),
but not elsewhere.

dict_stats_save_defrag_summary(), dict_stats_save_defrag_stats():
If the transaction is in read-only mode, return DB_READ_ONLY
and do not attempt to lock or modify anything.

Windows builds failed due to the following error:
'#': invalid character: possibly the result of a macro expansion

The commit e954d9de gave different lifetime to wide_share and
partition_handler_share. This introduced the possibility that
partition_handler_share could be accessed even after it was freed.

We stop sharing partitoiin_handler_share and make it belong to
a single wide_handler to fix the problem.

In MDEV-14425, an early plan was to introduce a separate log file
for file-level records and checkpoint information. The reasoning was
that fil_system.mutex contention would be reduced by not having to
maintain fil_system.named_spaces. The mutex contention was actually
fixed in MDEV-23855 by making some data fields in fil_space_t and
fil_node_t use std::atomic.

Using a single circular log file simplifies recovery and backup.

The function buf_page_free() that was introduced
in commit a35b4ae8 (MDEV-15528)
failed to remove any adaptive hash index entries for the page
before freeing the page.

This caused an assertion failure on shutdown of 10.6 server of
in the function buf_pool_t::clear_hash_index() with the expression:
(s >= buf_page_t::UNFIXED || s == buf_page_t::REMOVE_HASH).
The assertion would fail for a block that is in the freed state.

The failing assertion was added in
commit aaef2e1d
in the 10.6 branch.

Thanks to Matthias Leich for finding the bug and testing the fix.

buf_page_get_gen(): After recv_sys_t::recover_low() returned,
the page must not be read-fixed, but it may be write-fixed,
because the io-fix state is protected by block->page.lock,
which we are not holding yet.

Also, let us copy the block descriptor state to a local variable
for examination, so that in case an assertion would fail again,
we will have the sampled state in the core dump. In a core dump of
the assertion failure, we had block->page.fix() == buf_page_t::UNFIXED,
that is, the assertion expression was holding again.

create_table_info_t::create_foreign_keys() expects equal number of
iterations through fk->columns and fk->ref_columns. If fk->ref_columns
is empty copy it from fk->columns.

This follows up commit 017d1b86.
In commit aaef2e1d (MDEV-27058)
some more problematic debug assertions were added.

btr_search_update_block_hash_info(), trx_purge_truncate_history():
Use simpler assertions to check that an uncompressed page is present.

mtr_t::modify(): Remove a debug assertion that had been added
in commit 05fa4558 (MDEV-22110).
The function buf_pool_t::is_uncompressed() is only safe to invoke
while holding a buf_pool.page_hash latch so that buf_pool_t::resize()
cannot concurrently invoke free() on any chunks.

The problem was introduced by the removal of buf_pool.flush_rbt
in commit 46b1f500 (MDEV-23399)

recv_sys_t::apply(): don't write to disc and fsync() the last batch.
Insead, sort it by oldest_modification for MariaDB server and some
mariabackup operations.

log_sort_flush_list(): a thread-safe function which sorts buf_pool::flush_list

trx_has_lock_x() fails to find whether the trx has X-lock on the table
when other transactions are waiting for an X or S lock on the table.

There was an intention to add a CommandQueue in
mysql/mysql-server@eca5b0fc17a5bd6d4833d35a0d08c8549dd3b5ec
but it never appeared in any release (not even MySQL 5.7.3
where that commit appeared).

Diagnostics_area::set_error_status (interrupted ALTER TABLE under LOCK)

Analysis: KILL_QUERY is not ignored when local memory used exceeds maximum
session memory. Hence the query proceeds, OK is sent and we end up
reopening tables that are marked for reopen. During this, kill status is
eventually checked and assertion failure happens during trying to send error
message because OK has already been sent.
Fix: Ok is already sent so statement has already executed. It is too
late to give error. So ignore kill.

The warning reads:

CMake Deprecation Warning at CMakeLists.txt:101 (CMAKE_MINIMUM_REQUIRED):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

In commit 18535a40 (MDEV-24811)
the implementation of innodb_evict_tables_on_commit_debug
depended on dict_sys.mutex and SAFE_MUTEX.
That is no longer the case.

SAFE_MUTEX is not available on Microsoft Windows.