trx_purge_truncate_history(): Do not force a write of the undo tablespace
that is being truncated. Instead, prevent page writes by acquiring
an exclusive latch on all dirty pages of the tablespace.

fseg_create(): Relax an assertion that could fail if a dirty undo page
is being initialized during undo tablespace truncation (and
trx_purge_truncate_history() already acquired an exclusive latch on it).

fsp_page_create(): If we are truncating a tablespace, try to reuse
a page that we may have already latched exclusively (because it was
in buf_pool.flush_list). To some extent, this helps the test
innodb.undo_truncate,16k to avoid running out of buffer pool.

mtr_t::commit_shrink(): Mark as clean all pages that are outside the
new bounds of the tablespace, and only add the newly reinitialized pages
to the buf_pool.flush_list.

buf_page_create(): Do not unnecessarily invoke change buffer merge on
undo tablespaces.

buf_page_t::clear_oldest_modification(bool temporary): Move some
assertions to the caller buf_page_write_complete().

innodb.undo_truncate: Use a bigger innodb_buffer_pool_size=24M.
On my system, it would otherwise hang 1 out of 1547 attempts
(on the 40th repeat of innodb.undo_truncate,16k).
Other page sizes were not affected.

At least since commit 055a3334
(MDEV-13564) the undo log truncation in InnoDB did not work correctly.

The main issue is that during the execution of
trx_purge_truncate_history() some pages of the newly truncated
undo tablespace could be discarded.

This is improved from commit 1cb218c3
which was applied to earlier-version branches.

fsp_try_extend_data_file(): Apply the peculiar rounding of
fil_space_t::size_in_header only to the system tablespace,
whose size can be expressed in megabytes in a configuration parameter.
Other files may freely grow by a number of pages.

fseg_alloc_free_page_low(): Do allow the extension of undo tablespaces,
and mention the file name in the error message.

mtr_t::commit_shrink(): Implement crash-safe shrinking of a tablespace:
(1) durably write the log
(2) release the page latches of the rebuilt tablespace
(3) release the mutexes
(4) truncate the file
(5) release the tablespace latch
This is refactored from trx_purge_truncate_history().

log_write_and_flush_prepare(), log_write_and_flush(): New functions
to durably write log during mtr_t::commit_shrink().

While the redo log is being resized in srv_start(),
we must not write checkpoint information to the old log.

Thanks to Matthias Leich for noticing this.

MDEV-24629 mariadb-connector-c-config conflicts with MariaDB's MariaDB-common-10.5.8-1.fc32.x86_64.rpm

this fix is adding alternative name to MariaDB-common on Fedora.
the fix is placed outside of IF/ELSEIF blocks to do not overwrite
existing one for Fedora.

Results with
```
%define api.pure                                    /* We have threads */
```
in `<build-dir>/sql/[yy_mariadb|yy_oracle].yy` files.

Reviewed by: wlad@mariadb.com

Avoid reading uninitialized memory by  thd_get_error_context_description().
Note, that THD::real_id can't be initialized at this stage, so it will be zeroed.

The issue is that max_length for prepared statements are different from
normal queries, which can optimize the max_length based on the result
length.

MDEV-19950 addendum: galera_ssl_upgrade removed from the list of disabled tests and adapted for 10.4+

Problem was that there was extra condition !thd->lex->no_write_to_binlog
before call to begin TOI. It seems that this variable is not initialized.
TRUNCATE does not support [NO_WRITE_TO_BINLOG | LOCAL] keywords, thus
we should not check this condition. All this was hidden in a macro,
so I decided to remove those macros that were used only a few places
with actual function calls.

buf_flush_page_cleaner(): Always try to advance the log checkpoint,
even when no pages were flushed during the latest batch.
Maybe, since the previous batch, there was an LRU flush that
removed the last dirty pages.

Failure to advance the log checkpoint will cause unnecessary work
in Mariabackup and on crash recovery.

This was required as I added a new error code to my_base.h and rocksdb
is adding it's own errors after the last official one

Updated result file also for index_merge_rocksdb2. This is a big test
and we have probably not before noticed that some optimizer changes
caused a difference.

MDEV-26621 assertion failue "index->table->persistent_autoinc" in /storage/innobase/btr/btr0btr.cc during IMPORT

dict_index_t::clear_instant_alter(): when searhing for an AUTO_INCREMENT column
don't skip the beginning of the list because the field can be at the beginning of the list

This bug happens when one runs aria_chk on multiple tables. It does not
affect REPAIR TABLE.
aria_chk tries to optimize the sort buffer size to minimize memory usage
when used with small tables. The bug was that the adjusted value was
used as a base for the next table, which could cause problems.

Fixed also an error in suite/perfschema/t/transaction_nested_events-master.opt

- Error on commit now returns HA_ERR_COMMIT_ERROR instead of
  HA_ERR_INTERNAL_ERROR
- If checkpoint fails, it will now print out where it failed.

instead of original name of the column

When doing refactoring of temporary table field creation a mistake was
done when copying the column name when creating internal temporary tables.
For internal temporary tables we should use the original field name, not
the item name (= alias).

Thanks to Fabian Vogt for noticing the mutual exclusions
of these open flags on tmpfs caused by mariadb opening it
incorrectly.

As such we clear the O_CREAT flag while opening it as O_TMPFILE.

Fix sporadic failure for MTR test galera_sr.GCF-1018B. The test
sometimes fails due to an error that is logged to the error log
unnecessarily.
A deterministic test case (included in this patch) shows that the
error is loggen when a transaction is BF aborted right before  it
opens the streaming log table to perform fragment removal. When that
happens, the attempt to open the table fails and consequently an error
is logged. There is no need to log this error, as an ER_LOCK_DEADLOCK
error is returned to the client.
Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>

The debian/salsa-ci.yml used to work also on upstream MariaDB.org branches,
but has recently regressed and several jobs stopped working. These fixes
are necessary to get it working again.

* Partially revert 8642f592 that never worked, as MariaDB 10.2 does not
  have a mysql.global table nor a mariadb.sys user. Those features weren't
  introduced until MariaDB 10.4.

* Partially revert 0268b871 as we don't want ColumnStore as part of the
  native Debian build. It should build only when the build is triggered
  via autobake-deb.sh (MariaDB.org builds).

* Adjust salsa-ci.yml to cope with various Stretch to Sid upgrade issues
  and remove the legacy mariadb-connector-c job completely as that package
  hasn't been around for years anymore.

* Extend Lintian overrides to be otherwise Lintian clean

set_item() uses 1UL << bit, so is_set_item() must do the same.

This fixes sporadic perfschema.show_aggregate failures
(sporadic, because `bit` is the thread id, so depending on how many
tests were run before perfschema.show_aggregate it can be above or
below 32).

# Conflicts:
#	appveyor.yml

# Conflicts:
#	cmake/os/Windows.cmake
#	sql/sql_yacc.yy

A conversion warning 4267 that we want to disable(prior to 10.3),
was suppressed with  cmake VS generator for C++ and C, despite being set
only for CXX flags.

The fix is to disable the warning in C flags, too. In 10.2, this warning
is noisy, in 10.3 it is fixed.

instead, include handler_rollback in the following per-connection selects

The merge accidentally
omitted the 10.4 commit 472b35c7 and
reverted the 10.5 commit 6e3bd663.