MDEV-18173 Assertion `o->ind == vers_end' or `o->ind == vers_start' failed in dict_table_t::instant_column

The purpose of buf_pool->flush_rbt is to ensure that
buf_pool->flush_list is ordered by oldest_modification.
This should speed up multi-pass redo log application
(when the buffer pool is not large enough to accommodate
all pages that were modified since the latest log checkpoint).

The buf_pool->flush_rbt is not being used after redo log has
been applied. It could be better to always flush pages in
the ascending order of oldest_modification. Currently, whenever
a page is first modified, it will be moved to the start of the
buf_pool->flush_list, overtaking blocks whose oldest_modification
could be much older.

buf_flush_insert_sorted_into_flush_list(): Merge into
buf_flush_insert_into_flush_list().

buf_flush_recv_note_modification(): Remove.
The function buf_flush_note_modification() can be invoked instead.

btr_cur_pessimistic_insert(): Do not attempt to convert the
metadata BLOB to external storage if it has already been converted.
It could have been converted by btr_cur_pessimistic_update().
Relax some over-zealous assertions.

dtuple_convert_big_rec(): Assert that the metadata BLOB has
not been converted yet.

btr_cur_instant_init_low(): Fix the typo in the computation
of the trx_id_offset of a metadata record.

Simplified mutex code. MutexDebug uses OSMutex instead of
atomic operations now.

- Changed the performance schema query which gives sampling with event
counting. It should fix the issue.

dict_table_t::instant_column(): Correctly compute the value of
metadata_changed. The original computation in
commit 00372075 would essentially
invoke memcmp(x,x,y), which can only return 0.

buf_page_t::buf_fix_count transition to Atomic_counter.

Replaced srv_fatal_semaphore_wait_threshold juggling with
btr_validate_index_running counter.
Removed last argument of btr_validate_index(): always false.
Simplified away btr_validate_spatial_index().

Make mariabackup.sh compatible on FreeBSD

Fix an inadvertently inverted condition that caused
galera.galera_sst_mariabackup_table_options test failure.

MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page corruption detected at page 1

If an encrypted table is created during backup, then
mariabackup --backup could wrongly fail.

This caused a failure of the test mariabackup.huge_lsn once on buildbot.

This is due to the way how InnoDB creates .ibd files. It would first
write a dummy page 0 with no encryption information. Due to this,
xb_fil_cur_open() could wrongly interpret that the table is not encrypted.
Subsequently, page_is_corrupted() would compare the computed page
checksum to the wrong checksum. (There are both "before" and "after"
checksums for encrypted pages.)

To work around this problem, we introduce a Boolean option
--backup-encrypted that is enabled by default. With this option,
Mariabackup will assume that a nonzero key_version implies that the
page is encrypted. We need this option in order to be able to copy
encrypted tables from MariaDB 10.1 or 10.2, because unencrypted pages
that were originally created before MySQL 5.1.48 could contain nonzero
garbage in the fields that were repurposed for encryption.

Later, MDEV-18128 would clean up the way how .ibd files are created,
to remove the need for this option.

page_is_corrupted(): Add missing const qualifiers, and do not check
space->crypt_data unless --skip-backup-encrypted has been specified.

xb_fil_cur_read(): After a failed page read, output a page dump.