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.

The error message "InnoDB: innodb_page_size=65536 requires innodb_buffer_pool_size >= 20MiB current 10MiB" is the relevant one.

The root cause:
mysql_install_db bootstraps with --innodb-buffer-pool-size=10M.
Small bufferpool is here by design - bootstrap should succeed,
even if there is not much RAM available, bootstrap does not need that much
memory.

For pagesize 64K specifically, Innodb thinks it needs a larger bufferpool,
and thus it lets the bootstrap process die (although the expected behavior
in this case would be to adjust value, give warning and continue)

The workaround:
- pass --innodb-buffer-pool-size=20M, which is suitable for all page sizes.
- check the same limit in MSI custom action.

Also, the patch adds mtr test for 64K page size.