Upgrade from pre-10.5.10 to 10.5.10 causes CHECK errors on encrypted Aria tables

• bootstrap 10.5.9 with aria-encrypt-tables=1, e.g.

  --aria-encrypt-tables=1 --file-key-management --file-key-management-filename=`pwd`/mysql-test/std_data/keys.txt --plugin-load-add=file_key_management

• start 10.5.10 on the datadir from 10.5.9;
• run CHECK TABLE `mysql`.`tables_priv`

  10.5 8426c741
  MariaDB [(none)]> CHECK TABLE `mysql`.`tables_priv`;
  +-------------------+-------+----------+----------------------------------------------------------------------------------------------------------------------------------+
  | Table | Op | Msg_type | Msg_text |
  +-------------------+-------+----------+----------------------------------------------------------------------------------------------------------------------------------+
  | mysql.tables_priv | check | error | Page at 8192 as wrong LSN (3971177,0x66334873). Current LSN is (1,0x5a5b) |
  | mysql.tables_priv | check | error | Page at 16384 as wrong LSN (11590737,0x19495cff). Current LSN is (1,0x5a5b) |
  | mysql.tables_priv | check | error | Page 1: Wrong LSN (9127271,0x327b23c6). Current LSN is (1,0x5a5b) |
  | mysql.tables_priv | check | error | Table is probably from another system and must be zerofilled or repaired ('REPAIR TABLE table_name') to be usable on this system |
  | mysql.tables_priv | check | error | Corrupt |
  +-------------------+-------+----------+----------------------------------------------------------------------------------------------------------------------------------+
  5 rows in set (0.012 sec)

The problem was introduced by this commit in 10.5.10:

commit 81258f14323e1d1ad0203bae93bc55a30d47c1b3 (HEAD)

Author: Monty <monty@mariadb.org>

Date:   Fri Apr 2 22:00:36 2021 +0300

    MDEV-17913 Encrypted transactional Aria tables remain corrupt after crash recovery, automatic repairment does not work

...

    Other things:

    - Extended Aria check_table() to check for wrong (= too big) LSN numbers.

    - If check_table() failed just because of wrong LSN or TRN numbers,

      a following repair table will just do a zerofill which is much faster.

    - Limit number of LSN errors in one check table to MAX_LSN_ERROR (10).

    - Removed old obsolete test of 'if (error_count & 2)'. Changed error_count

      and warning_count from bits to numbers of errors/warnings as this is

      more useful.

I don't know whether it is a real problem or the extended check produces false positives, but in any case corruption-like errors can cause troubles for users.

REPAIR makes the errors disappear.