- 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

ha_rocksdb.h:459:15: warning: 'table_type' overrides a member
function but is not marked 'override' [-Winconsistent-missing-override]

It turns out that WFRM_WRITE_EXTRACTED was added only in a debug
assertion and in a comment, as part of
commit b7bba721.

The assert inside String::copy() prevents copying from from "str"
if its own String::Ptr also points to the same memory.

The idea of the assert is that copy() performs memory reallocation,
and this reallocation can free (and thus invalidate) the memory pointed by Ptr,
which can lead to further copying from a freed memory.

The assert was incomplete: copy() can free the memory pointed by its Ptr
only if String::alloced is true!

If the String is not alloced, it is still safe to copy even from
the location pointed by Ptr.

This scenario demonstrates a safe copy():
  const char *tmp= "123";
  String str1(tmp, 3);
  String str2(tmp, 3);
  // This statement is safe:
  str2.copy(str1->ptr(), str1->length(), str1->charset(), cs_to, &errors);

Inside the copy() the parameter "str" is equal to String::Ptr in this example.
But it's still ok to reallocate the memory for str2, because str2
was a constant before the copy() call. Thus reallocation does not
make the memory pointed by str1->ptr() invalid.

Adjusting the assert condition to allow copying for constant strings.