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.

that is not in binlog.

Post-crash recovery of --rpl-semi-sync-slave-enabled server
failed to recognize a transaction in-doubt that needed rolled back.
A prepared-but-not-in-binlog transaction gets committed instead
to possibly create inconsistency with a master (e.g the way it was observed
in the bug report).

The semisync recovery is corrected now with initializing binlog coordinates
of any transaction in-doubt to the maximum offset which is
unreachable.
In effect when a prepared transaction that is not found in binlog
it will be decided to rollback because it's guaranteed to reside
in a truncated tail area of binlog.

Mtr tests are reinforced to cover the described scenario.

commit 84984b79 is null-merged

This commit sends a flag indicating the presence of the "--bypass"
option from the donor node to the joiner nodes during rsync IST,
because without such a flag it is impossible to distinguish IST
from the SST on the joiner nodes (in IST/SST scripts, because the
"--bypass" option is still not passed to scripts from server code).
Specifically, this fixes an issue with binary logs disappearing
after IST (via rsync). There are also changes to diagnostic messages
here that will make it easier to diagnose script-related problems
in the future when debugging and when checking the logs. This commit
also adds more robust signal handlers - to handle exceptions during
script execution. These handlers won't mask some crashes and it
also unifies exit codes between different scripts. These changes
have already been helpful to debugging "bypass" flag handling.

This commit fixes an issue with IST handling in
version 10.9 which is a regression after MDEV-26971
and related to trying to get a non-existent "total"
tag on the IST branch (this tag is only defined in
SST mode).

We cannot permanently change bits in read_partitions in the middle of
processing because ha_rnd_init()/ha_rnd_end() depends on that.

prefer if/skip over require
(works better with debugging, not affected by query log)

followup for c9b5a053

This reverts commit 17e0f522.

Function wsrep_read_only_option was already removed in commit
d54bc3c0 because it could cause race condition on variable
opt_readonly so that value OFF can become permanent.
Removed function again and added test case. Note that writes
to TEMPORARY tables are still allowed when read_only=ON.

same as MDEV-26412, but in CREATE...SELECT.
fix: apply 39feab3c to create rule too.

The counter srv_stats.key_rotation_list_length is never updated, and
therefore Innodb_encryption_key_rotation_list_length will always be 0.

The view INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION comes close
to reporting this information.

The counters were added in commit 5e55d1ce
and any code to update them was
inadvertently removed in commit 2e814d47
when applying InnoDB changes from MySQL 5.7.

Let us remove these counters that never reported anything useful. If such
statistics are really needed in a special case, they can be obtained by
instrumenting the code by some means, such as eBPF or a source code patch.

This patch fixes a problem that arises when a Galera node acts as a
replica for native replication. When parallel applying is enabled, it
is possible to end up with attempts to write binlog events with gtids
out of order. This happens because when multiple events are delivered
from the native replication stream and applied in concurrently, it is
for them to be replicated to the Galera cluster in an order which is
different from the original order in which they were committed in the
aync replication master.
To correct this behavior we now wait_for_prior_commit() before
replicating changes though galera. As a consequence, parallel appliers
may apply events in parallel until the galera replication step, which
is now serialized.

Add disconnect.

Decrease the number of tables and operations.

Arythmetic can overrun the uint type when possible group_concat_max_len
is multiplied to collation.mbmaxlen (can easily be like 4).
So use ulonglong there for calculations.

followup for d16c3aca

to make the all headers -std=c++20 clean for those, who need c++20
(some plugins)

The warning comes from copying POSITION objects where 'type' is not
initialized.  This does not affect any production code as when 'type'
was compared/used, it was always initialized.

Removed by initializing the type variable in the constructor

- In best_extension_by_limited_search(), do not check for
  "(remaining_tables & real_table_bit)", it is guaranteed to be true.
  Make it an assert.
- In (!idx || check_interleaving_with_nj())", remove the !idx part.
  This check made sense only in the original version of this function.
- "micro optimization" in check_interleaving_with_nj().

The condition of the if statements are always true.