Main patch MDEV-27896 Wrong result upon `COLLATE latin1_bin CHARACTER SET latin1` on the table or the database level

Also fixes
MDEV-27782 Wrong columns when using table level `CHARACTER SET utf8mb4 COLLATE DEFAULT`
MDEV-28644 Unexpected error on ALTER TABLE t1 CONVERT TO CHARACTER SET utf8mb3, DEFAULT CHARACTER SET utf8mb4

Improve and add more languages for the ERROR 1476: Foreign Server
already exists.

The debian/mariabd-plugin-columnstore.install should
not have been committed. It was removed on other branches,
just 10.6 was missed. This prevented packages being built
because the debain/control wasn't populated.

Commit introduces automatic detection which supported
Perl MariaDB DBI driver is available:

 * DBD::mysql
 * DBD::MariaDB

If nothing is then bail out and die

Current Detection prefers Perl DBD:MariaDB driver.

This is mainly for older Linux distros or Windows which does not
have Perl DBD:MariaDB packaged or does not want to use Perl cpan command.

Improve and add more languages for the ERROR 1476: Foreign Server
already exists.

MariaDB Debian packages does not have version suffix anymore since MariaDB version 10.9.
This makes obsolete need for the suffix in debian/control file.

Fix Lintian errors:

E: mariadb source: version-substvar-for-external-package Conflicts (line 408) ${source:Version} mariadb-client -> mariadb-client-10.9
E: mariadb source: version-substvar-for-external-package Conflicts (line 575) ${source:Version} mariadb-server-core -> mariadb-server-core-10.9
E: mariadb source: version-substvar-for-external-package Conflicts (line 711) ${source:Version} mariadb-server -> mariadb-server-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 330) ${source:Version} mariadb-client-core -> mariadb-client-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 330) ${source:Version} mariadb-client-core -> mariadb-server-core-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 481) ${source:Version} mariadb-client -> mariadb-client-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 481) ${source:Version} mariadb-client -> mariadb-client-core-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 481) ${source:Version} mariadb-client -> mariadb-server-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 481) ${source:Version} mariadb-client -> mariadb-server-core-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 626) ${source:Version} mariadb-server-core -> mariadb-client-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 626) ${source:Version} mariadb-server-core -> mariadb-server-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 748) ${source:Version} mariadb-server -> mariadb-client-10.9
E: mariadb source: version-substvar-for-external-package Replaces (line 748) ${source:Version} mariadb-server -> mariadb-server-10.9

When reading the man page of e.g. 'mysql' on a system with MariaDB
installed one would actually see the man page of 'mariadb'. However the
man page had no indication of the page being for 'mariadb', which was
confusing for users.

Fix this by updating the man page title lines to use mariadb-* instead
of mysql* for MariaDB binaries that are drop-in replacements for MySQL
equivalents, indicating that the commands are actually of the MariaDB
version.

In long term, all the commands in man pages should be replaced by their
MariaDB counterparts. Update the title lines as a start, and only those
that exist as symlinks to their MariaDB counterparts.

Before:

    man mariadb-upgrade | head -n 1
    MYSQL_UPGRADE(1) ...

After:

    man mariadb-upgrade | head -n 1
    MARIADB-UPGRADE(1) ...

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.

Depending on OpenSSL version, and at least in 3.0.3, the client-side socket
timeout is reported as generic error (SSL_ERROR_SYSCALL), losing further
details (both errno and GetLastError() return 0). This results in client
reporting "Unknown OpenSSL error" 2026, instead of another generic
"Lost connection to server during query" 2013

Adjusted test case.

OpenSSL 3.0.0+ does not support EVP_MD_CTX_FLAG_NON_FIPS_ALLOW any longer.
In OpenSSL 1.1.1 the non FIPS allowed flag is context specific, while
in 3.0.0+ it is a different EVP_MD provider.

Fixes #2010

part of MDEV-28133

This reverts commit c9beef43, because
we have OpenSSL 3.0 support here.

part of MDEV-28133

Summary of changes

- MD_CTX_SIZE is increased

- EVP_CIPHER_CTX_buf_noconst(ctx) does not work anymore, points
  to nobody knows where. The assumption made previously was that
  (since the function does not seem to be documented)
  was that it points to the last partial source block.
  Add own partial block buffer for NOPAD encryption instead

- SECLEVEL in CipherString in openssl.cnf
  had been downgraded to 0, from 1, to make TLSv1.0 and TLSv1.1 possible
   (according to https://github.com/openssl/openssl/blob/openssl-3.0.0/NEWS.md
   even though the manual for SSL_CTX_get_security_level claims that it
   should not be necessary)

- Workaround Ssl_cipher_list issue, it now returns TLSv1.3 ciphers,
  in addition to what was set in --ssl-cipher

- ctx_buf buffer now must be aligned to 16 bytes with openssl(
  previously with WolfSSL only), ot crashes will happen

- updated aes-t , to be better debuggable
  using function, rather than a huge multiline macro
  added test that does "nopad" encryption piece-wise, to test
  replacement of EVP_CIPHER_CTX_buf_noconst

part of MDEV-28133

Step#3 MDEV-27896 Wrong result upon `COLLATE latin1_bin CHARACTER SET latin1` on the table or the database level

Splitting Lex_exact_charset_extended_collation_attrs_st into small components.

- Adding classes:
  * Lex_exact_charset
  * Lex_context_collation
  * Lex_exact_collation
  * Lex_extended_collation_st
  * Lex_extended_collation
  and moving pieces of the code from methods
  * merge_charset_clause_and_collate_clause()
  * merge_collate_clause_and_collate_clause()
  into smaller methods in the new classes.
  It's easier to read, handle and reuse the code this way.

- Moving static methods find_default_collation() and find_binary_collation()
  from Lex_exact_charset_extended_collation_attrs_st to non-static methods in
  Lex_exact_charset_opt_extended_collate, as now it's a better place for them.

- Using Lex_extended_collation_st in sql_yacc.yy to handle COLLATE clauses,
  to handle both context and extended collations
  (instead of the previous notation with NULL CHARSET_INFO pointer
   meaning DEFAULT, and not-NULL meaning an exact collation).
  This change will also help to add more context (UCA1400) collations soon.
  The old notation with CHARSET_INFO won't be enough.

- Adding LEX::set_names() and reusing it in two places in sql_yacc.yy

- Removing the opt_collate_or_default rule. It's was used only
  to handle the CONVERT TO related grammar. Had to add some code duplication,
  but it will be gone in one of the next commits.

This change will also soon help to add
Lex_extended_charset_extended_collation_attrs_st -
a new class to handle table and database level CHARACTER SET and COLLATE
clauses easier.

Step#2 MDEV-27896 Wrong result upon `COLLATE latin1_bin CHARACTER SET latin1` on the table or the database level

- Renaming Lex_charset_collation_st to
  Lex_exact_charset_extended_collation_attrs_st

- Renaming Lex_explicit_charset_opt_collate to
  Lex_exact_charset_opt_extended_collate

- Renaming their methods charset_collation() to charset_info(),
  so the name clearly tells that it returns CHARSET_INFO.
  Soon we'll have new classes (e.g. Lex_exact_collation) and
  methods returning Lex_exact_collation. So the old name would be
  confusing about the return type.

Step#1 MDEV-27896 Wrong result upon `COLLATE latin1_bin CHARACTER SET latin1` on the table or the database level

- Adding data type aliases:
  using Lex_column_charset_collation_attrs_st = Lex_charset_collation_st;
  using Lex_column_charset_collation_attrs = Lex_charset_collation;

  and using them all around the code (except lex_charset.*)
  instead of the original names.

- Renaming Lex_field_type_st::lex_charset_collation()
  to charset_collation_attrs()

- Renaming Column_definition::set_lex_charset_collation()
  to set_charset_collation_attrs()

- Renaming Column_definition::lex_charset_collation()
  to charset_collation_attrs()

Rationale:

The name "Lex_charset_collation" was a not very good name.
It does not tell details about its properties:
1. if the charset is optional (yes)
2. if the collation is optional (yes)
3. if the charset can be exact (yes) or context (no)
4. if the collation can be: exact (yes) or context (yes)
5. if the clauses can be repeated multiple times (yes)

We'll need a few new data types soon with different properties.
For example, to fix MDEV-27896 and MDEV-27782, we'll need a new
data type which is very like Lex_charset_collation, but additionally
supports CHARACTER SET DEFAULT (which is allowed on table and database level,
but is not allowed on the column level yet), i.e. with:
  "the charset can be exact (yes) or context (yes)" in N3.

So we'll have to rename Lex_charset_collation to something else,
e.g.: Lex_exact_charset_extended_collation_attrs,
and add a new data type:
e.g. Lex_extended_charset_extended_collation_attrs

Also, we'll possibly allow CHARACTER SET DEFAULT at the column level for
consistency with other places. So the storge on the column level can change:
- from Lex_exact_charset_extended_collation_attrs
- to   Lex_extended_charset_extended_collation_attrs

Adding the aliases introduces a convenient abstraction against
upcoming renames and c++ data type changes.

The variable, spider_buffer_size, is used nowhere in the MariaDB Community Server.

Suspend
 national-encoding
 repeated-path-segment
 package-contains-documentation-outside-usr-share-doc

Package mariadb-test-data has test files
in directory '/usr/share/mysql/mysql-test/' which are not UTF-8
encoded and they should not be as they are for testing.

package also have Lintian warnings for files that
are not in correct place in directory 'usr/share/mysql/mysql-test'
but as they are all are test results they are not in incorrect place

At last there is intentional use for some repeated directories so
they are false-positives and should be suspended