InnoDB fails to rollback the bulk insert buffered operation when
trx_mark_sql_stat_end() encounters the DB_DUPLICATE_KEY error.
In this case, check table fails with secondary index row count
mismatch. InnoDB gives the error "ER_ERROR_DURING_COMMIT"
while encountering the DB_DUPLICATE_KEY in trx_mark_sql_stat_end()

fix test failures on rpm-centos73-ppc64

followup for 401ff699

it's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
fixed in 2011
affects fmtlib: https://github.com/fmtlib/fmt/issues/1936

add a test case

MDEV-26742 Assertion `field->type_handler() == this' failed in FixedBinTypeBundle<NATIVE_LEN, MAX_CHAR_LEN>::Type_handler_fbt::stored_field_cmp_to_item

The bug was fixed in 10.5 using INET6 specific tests.

This bugs adds only UUID specific tests (no code changes).

UUID values

  llllllll-mmmm-Vhhh-vsss-nnnnnnnnnnnn

are now stored as

  nnnnnnnnnnnn-vsss-Vhhh-mmmm-llllllll

inside the record:

- the groups (segments separated by dash) are reordered right-to-left.
- the bytes inside the groups are not reordered (stored as before,
  in big-endian format).

This provides a better sorting order: the earlier UUID was generated,
the higher it appears in the ORDER BY output.

Also, this change enables a good key prefix compression,
because the constant part is now in the beginning, while
the non-constant part (the timestamp) is in the end.

- Adding a new template FixedBinTypeStorage.

- Restoring classes UUID and Inet6
  as primitive "storage classes" for their data types.
  They derive from FixedBinTypeStorage.
  These storage classes have very few server dependencies so they
  can later be easily reused in smart engines, e.g. ColumnStore.

- Changing the FixedBinTypeBundle parameter from
  <size_t NATIVE_LEN, size_t MAX_CHAR_LEN> to <class FbtImpl>
  and fixing UUID and INET6 bundles to get their storage
  classes as a parameter.

factor out the the common code for all plugin types that have a
fixed-length native binary representation and a possibly variable-length
string representation.

Locking / unlocking plugins is already handled by Sys_var_plugin::check
method. No need to do that in the specialized checking code, use
var->save_value instead to get the plugin handle.

The InnoDB changes in MySQL 5.7.36 that were applicable to MariaDB
were covered by MDEV-26864, MDEV-26865, MDEV-26866.

The initial test case for MySQL Bug #33053297 is based on
mysql/mysql-server@27130e25078864b010d81266f9613d389d4a229b.

innobase_get_field_from_update_vector is not a suitable function to fetch
updated row info, as well as parent table's update vector is not always
suitable. For instance, in case of DELETE it contains undefined data.

castade->update vector seems to be good enough to fetch all base columns
update data, and besides faster, and less error-prone.

In the replication-related code, in the exec_relay_log_event() (slave.cc)
function, where the "data_lock" mutex is captured, this mutex is then not
released on one of the early return branches within a specific insert for
WSREP, namely under the branch: "if (wsrep_before_statement(thd))". As a
result, the mutex remains captured, resulting in errors or hangs.

This commit fixes this issue, which is now showing up as intermittent
failures in mtr tests for galera and galera_sr suites.

Similar to commit f7684f0c (MDEV-26855)
we will try to enable the adaptive spinloop for lock_sys.wait_mutex
on ARMv8.

Enabling any form of spinloop for lock_sys.wait_mutex did not show a
significant improvement in our tests on AMD64.

Spinning can be argued to be a hack to reduce the impact on mutex
contention. It would be better to adjust the code to reduce
contention in the first place.

because plugin code is not only about encryption anymore
(also loads provider plugins), and xb_ prefix prevents name
clashes with the server code (that mariabackup links with).

prefer backup-my.cnf from the incremental-dir over the one in target-dir

* Change InnoDB message text to mention compression.
* make "not loaded compression provider" warning to be issued
  also when current_thd == 0.

make mariabackup to load not only encryption but also provider plugins.

like

==31311==ERROR: AddressSanitizer: odr-violation (0x7f3cda2e1480):
  [1] size=8 'provider_service_lz4' libservices/provider_service_lz4.c:14:17
  [2] size=8 'provider_service_lz4' sql/sql_plugin_services.ic:301:33

bzip2/lz4/lzma/lzo/snappy compression is now provided via *services*

they're almost like normal services, but in include/providers/
and they're supposed to provide exactly the same interface
as original compression libraries (but not everything,
only enough of if for the code to compile).

the services are implemented via dummy functions that return
corresponding error values (LZMA_PROG_ERROR, LZO_E_INTERNAL_ERROR, etc).

the actual compression libraries are linked into corresponding
provider plugins. Providers are daemon plugins that when loaded
replace service pointers to point to actual compression functions.

That is, run-time dependency on compression libraries is now on plugins,
and the server doesn't need any compression libraries to run, but
will automatically support the compression when a plugin is loaded.

InnoDB and Mroonga use compression plugins now. RocksDB doesn't,
because it comes with standalone utility binaries that cannot
load plugins.

if plugin->deinit() returns a failure, it is no longer ignored, it
means that the plugin isn't ready to be unloaded from memory yet.
So it's marked "dying", deinitialized as much as possible,
but stays in memory until shutdown.

also:

* increment MARIA_PLUGIN_INTERFACE_VERSION
* rewrite ha_rocksdb to use the new approach, update the test

* reduce code duplication