Parse CREATE TABLE statement, to perform data load without
secondary indexes. i.e temporarily drop secondary indexes and constraints
and recreate them after LOAD DATA INFILE.

This reduces random IO, and LOADING time, in many cases.

The behavior is guarded  by the new innodb_optimize_indexes option(default)

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`.