It currently serves no real purpose, but is suspected to cause occasional
error when foreign keys are used.
"Error: 1100, Table 'child' was not locked with LOCK TABLES, when using table: parent"
as seen on CI

1. it links with ${SSL_LIBRARIES}, in WolfSSL builds it's a static
   library, so when a plugin is loaded there will be two copies of
   wolfssl in the same address space. It breaks odr (at least).
2. Plugin can linked with OpenSSL and the server with WolfSSL or
   vice versa. It might load, but then we'll have both WolfSSL and
   OpenSSL at the same time. Kind of risky.

Fix: link the plugin statically into the server if it's a WolfSSL build

adjust tests to work with static and dynamic parsec

here MSAN complains that

==218853==WARNING: MemorySanitizer: use-of-uninitialized-value
   #0 0x7f84a77c60a3 in _gnutls_rnd_init /tmp/msan/lib/random.c:69:6
   #1 0x7f84a77c60a3 in gnutls_rnd /tmp/msan/lib/random.c:168:6

but the line lib/random.c:69 in gnutls-3.7.1 is

 69  	if (unlikely(!rnd_initialized)) {

and rnd_initialized is declared as

 40 static _Thread_local unsigned rnd_initialized = 0;

which apparently MSAN isn't happy with

PARSEC: Password Authentication using Response Signed with Elliptic Curve

new authentication plugin that uses salted passwords,
key derivation, extensible password storage format,
and both server- and client-side scrambles.

It signs the response with ed25519, but it uses stock
unmodified ed25519 as provided by OpenSSL/WolfSSL/GnuTLS.

Edited by: Sergei Golubchik

password handling as in other command-line tools

 and unsigned long long can not be used as bitfield.

Most other uses of ptr() are accompanied with a length, so we leave
them alone.

Before this change the unix socket auth plugin returned true only when
the OS socket user id matches the MariaDB user name.
The authentication string was ignored.

Now if an authentication string is defined with in `unix_socket`
authentication rule, then the authentication string will be used to
compare with the socket's user name, and the plugin will return a
positive if matching.

Make the plugin to fill in the @@external_user variable.

This change is similar to MySQL commit of
https://github.com/mysql/mysql-server/commit/6ddbc58e.
However there's one difference with above commit:

- For MySQL, both Unix user matches DB user name and Unix user matches the
  authentication string will be allowed to connect.
- For MariaDB, we only allows the Unix user matches the authentication
  string to connect, if the authentication string is defined.
  This is because allowing both Unix user names has risks and couldn't
  handle the case that a customer only wants to allow one single Unix user
  to connect which doesn't matches the DB user name.

If DB user is created with multiple unix_socket options for example:
`create user A identified via unix_socket as 'B' or unix_socket as 'C';`
Then both Unix user of B and C are accepted.

Existing MTR test of `plugins.unix_socket` is not impacted.
Also add a new MTR test to verify authentication with authentication
string. See the MTR test cases for supported/unsupported cases.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services, Inc.

in bintars the server is linked with wolfssl, while the connector
is linked with gnutls. Thus client_ed25519.so gets gnutls
dependency, unresolved symbols and it cannot be loaded into the
server and gnutls symbols aren't present there.

linking the plugin statically with gnutls fixes that and the test passes.
but when such a plugin is loaded into the client, the client gets
two copies of gnutls - they conflict and ssl doesn't work at all.

let's detect this and disable the test for now.

Client plugins on Debian are installed in a separate location,
outside of server's plugin-dir

note that:
* unit.conc_tls is broken in mtr
* schannel now doesn't fail on invalid ca path unless
  --ssl-verify-server-cert is used. openssl still does.

Fixes error:

/usr/share/mysql/debian-start.inc.sh: line 39: /usr/bin/mariadb --defaults-file=/etc/mysql/debian.cnf: No such file or directory

The slave would try to sync_with_master_gtid.inc,
but the master never actually saved its gtid position
so the test would move on too quickly.

Problem:
========
- After the commit ada1074b (MDEV-14398)
fil_crypt_set_encrypt_tables() iterates through all tablespaces to
fill the default_encrypt tables list. This was a trigger to
encrypt or decrypt when key rotation age is set to 0. But import
tablespace does call fil_crypt_set_encrypt_tables() unnecessarily.
The motivation for the call is to signal the encryption threads.

Fix:
====
ha_innobase::discard_or_import_tablespace: Remove the
fil_crypt_set_encrypt_tables() and add the import tablespace
to the default encrypt list if necessary

This test ran `show status like '%Created_tmp%'`. This captures
`Created_tmp_files` as well as the intended `Created_tmp_tables`.
In 11.5, the former got moved to `FLUSH GLOBAL`, so when testing, the
result can now be random.

This fix makes the test just use `Created_tmp_tables`.

Commit a8a75ba2 causes the MariaDB server to crash, usually with signal
11, at random code locations due to invalid pointer values during any
table operation. This issue occurs when the server is built with -O3 and
other customized compiler flags.

For example, the command `use db1;` causes server to crash in the
`check_table_access` function at line sql_parse.cc:7080 because
`tables->correspondent_table` is an invalid pointer value of 0x1.

The crashes are due to undefined behavior from using uninitialized
variables. The problematic commit a8a75ba2 introduces code that
allocates memory and sets it to 0 using thd->calloc before initializing
it with a placement new operation.
This process depends on setting memory to 0 to initialize member
variables not explicitly set in the constructor. However, the compiler
can optimize out the memset/bfill, leading to uninitialized values and
unpredictable issues.

Once a constructor function initializes an object, any uninitialized
variables within that object are subject to undefined behavior. The
state of memory before the constructor runs, whether it involves
memset or was used for other purposes, is irrelevant after the
placement new operation.

This behavior can be demonstrated with this
[test](https://gcc.godbolt.org/z/5n87z1raG) I wrote to examine the
assembly code. The code in MariaDB can be abstracted to the following,
though it has many layers wrapped around it and more complex logic,
causing slight differences in optimization in the MariaDB build.
To summarize, on x86, the memset in the following code is optimized out
with both -O2 and -O3 in GCC 13, and is only preserved in the much older
GCC 4.9.

    struct S {
      int i;     // uninitialized in consturctor
      S() {};
    };
    int bar() {
      void *buf = malloc(sizeof(S));
      memset(buf, 0, sizeof(S));       // optimized out
      S* s = new(buf) S;
      return s->i;
    }

With GCC13 -O3:

    bar():
          sub     rsp, 8
          mov     edi, 4
          call    malloc
          mov     eax, DWORD PTR [rax]
          add     rsp, 8
          ret

With GCC4.9 -O3

    bar():
          sub     rsp, 8
          mov     edi, 4
          call    malloc
          mov     DWORD PTR [rax], 0
          xor     eax, eax
          add     rsp, 8
          ret

Now we ensure the constructor initializes variables correctly by running
the reset() function in the constructor to perform the memset/bfill(0)
operation. After applying the fix, the crash is gone.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license. I am contributing on behalf of my employer Amazon Web
Services.

Remove an assert added by fix for MDEV-34417. BNL-H join can be used with
prefix keys. This happens when there are real prefix indexes on the
equi-join columns (although it probably doesn't make a lot of sense).

Anyway, remove the assert. The code receives properly truncated key values
for hashing/comparison so it can handle them just fine.

During InnoDB root page split, InnoDB does the following
1) First move the root records to the new page(p1)
2) Empty the root, insert the node pointer to the root page
3) Split the new page and make it as child nodes.
4) Finds the split record, allocate another new page(p2)
to the index
5) InnoDB stores the record(ret) predecessor to the supremum
record of the page (p2).
6) In page_copy_rec_list_start(), move the records from p1 to p2
upto the split record
6) Given table is a compressed row format page, InnoDB attempts to
compress the page p2 and failed (due to innodb_compression_level = 0)
7) Since the compression fails, InnoDB gets the number of preceding
records(ret_pos) of a record (ret) on the page (p2)
8) Page (p2) is a new page, ret points to infimum record.
ret_pos can be 0. InnoDB have wrong condition that ret_pos shouldn't
be 0 and returns corruption. InnoDB has similar wrong check in
page_copy_rec_list_end()

In commit bf0b82d2 (MDEV-33515)
the function log_t::init_lsn_lock() was removed. This was fine on
those platforms where InnoDB uses futex-based mutexes (Linux, FreeBSD,
OpenBSD, NetBSD, DragonflyBSD).

Dave Gosselin debugged this on Apple macOS and submitted a fix where
pthread_mutex_wrapper::pthread_mutex_wrapper() would invoke init().
We do not really need that; we only need to invoke lsn_lock.init()
like we used to do before commit bf0b82d2.
This should be a no-op for the futex based mutexes, which intentionally
rely on zero initialization.

The missing pthread_mutex_init() call would cause race conditions
and corruption of log_sys.buf because multiple threads could
apparently hold log_sys.lsn_lock concurrently in
log_t::append_prepare().  The error would be caught by a debug
assertion in log_t::write_buf(), or in non-debug builds by the
fact that the server cannot be restarted due to an apparently
missing FILE_CHECKPOINT record (because it had been written
to wrong offset in log_sys.buf).

The failure in log_t::append_prepare() was caught on Microsoft Windows
after enabling SUX_LOCK_GENERIC and therefore forcing the use of
pthread_mutex_wrapper for the log_sys.lsn_lock.  It appears to be fine
to omit the pthread_mutex_init() call on GNU/Linux.

log_t::create(): Invoke lsn_lock.init().

log_t::close(): Invoke lsn_lock.destroy().

To better catch this kind of issues in the future by simply defining
SUX_LOCK_GENERIC on any platform, a separate debug instrumentation patch
will be applied to the 10.6 branch later.

Reviewed by: Debarun Banerjee

- commit 85db5347 (MDEV-33400)
retains the instantness in the table definition after discard
tablespace. So there is no need to assign n_core_null_bytes
during instant table preparation unless they are not
initialized.