- Added a debug assert to unfix the block after applying the redo log
- Added store_recv in recv_sys_t::alloc() to make sure that
recv_t and recv_t::data is in the same block
- Added the assert which check buf_fix_count is 0 after applying
all redo log records.

- Remove recv_sys_t::heap, MEM_HEAP_FOR_RECV_SYS.
- Replaced recv_n_pool_free_frames with recv_sys.max_log_blocks.
- Removed available_mem variable in recv_parse_log_recs() and redo
log blocks threshold check is done with the help of recv_sys.max_log_blocks.
- Allocate the recv_sys.pages and its elements directly by
the system allocator.
- Allocate buffer pool blocks directly by buf_block_alloc().
Use block->unzip_LRU for keeping track of allocated blocks.
- Append log records to the last block, until the block->frame is
filled up. (Similar to the current recv_sys.heap.)
- Repurpose buf_block_t::modify_clock to store the length of the redo
log data.
- Use buf_block_t::page::buf_fix_count only in debug builds to count
the number of pointers from recv_sys.pages.

Changed Travis status to show status of branch 10.5 (it was still pointing to 10.4)

class log_file_t: more or less sane RAII wrapper around redo log file
descriptor and its path.

This change is motivated by the need of using that log_file_t somewhere else.

We missed these in commit 89633995
and commit ccd87d34.

os_file_flush_data_func(): fix builds on POSIX OSs where fdatasync()
is not avaiable

log_t::files::flush_data_only(): rename from fdatasync()

log_t::files::fsync(): removed and replaced with flush_data_only().
It will flush everything we need for using redo log files.

MDEV-21551 :  Assertion `m_active_threads.size() >= m_long_tasks_count + m_waiting_task_count' failed"

Happened when running innodb_fts.sync_ddl

m_long_task_count could be wrongly reset to 0, if m_task_queue is
empty.

dict_table_t::parse_name(): Properly calculate the *tbl_name_len.

A failure was easily repeatable during the test
innodb.innodb-alter-debug for the table name test.① ("test/@2460").
The UTF-8 representation of the U+2460 is only 3 bytes "\xe2\x91\xa0"
while the filename-safe encoded counterpart of it in dict_table_t::name
is 5 bytes "@2460".

This bug, introduced by commit ea37b144
(MDEV-16678), could cause a purge task to hang.

While waiting for mutex, thread_pool_generic::wait_begin(),
current task can be marked long-running. This is done by periodic
mantainence task, that runs in parallel.

Fix to recheck is_long_task() after the mutex acquisition.

I found that memcpy_aligned was used incorrectly at redo log and decided to put
assertions in aligned functions. And found even more incorrect cases.

Given the amount discovered of bugs, I left assertions to prevent future bugs.

my_assume_aligned(): instead of MY_ASSUME_ALIGNED macro

Made the test order_by_pack_big stable

An assertion added in commit c20bf8fd
includes a sign mismatch. Make the affected data members unsigned.

Since commit f52bf920 the type
Sql_sort is non-trivial, because it includes a data member
Bounds_checked_array<SORT_FIELD> local_sortorder.
There still is no vtable, so memset() is safe to invoke, but
we must add a cast to silence a warning in GCC 8 or later.

MDEV-21541: main.sum_distinct-big fails with Assertion `m_buffer_end == __null || end <= m_buffer_end'

For Merge_chuck structures first set the start and end positions of the buffer and
then adjust the end positions of the buffer if the records are dynamic in nature.

- Adding a way to define I_S columns without DEFAULT.
- Fixing all ENUM columns in I_S.INNODB* table definitions to have no DEFAULT.

maybe_wake_or_create_thread()

A task that is executed,could be counted as waiting (after wait_begin()
before wait_end()) or as long-running (callback runs for a long time).

If task is both marked waiting and long running, then calculation of
current concurrency (# of executing tasks - # of long tasks - #of waiting tasks)
is wrong, as task is counted twice.

Thus current concurrency could go negative, but with unsigned arithmetic
it will become a huge number.

As a result, maybe_wake_or_create_thread() would neither wake or create
a thread, when it should. Which may result in a deadlock.

Someone tried -DBUILD_SHARED_LIBS:BOOL=ON. This did not work well

threadpool has to know about long waits, to be able to create or wakeup
new threads, or it can become slow, if it just relies on maintainence
timer.

The merge commit ded128aa failed to adjust
commit 9d18b624 in debian/rules.
We must adjust the build path, which is derived from the package name,
which contains the major version number.

This task deals with packing the non-sorted fields (or addon fields).
This would lead to efficient usage of the memory allocated for the sort buffer.
The changes brought by this feature are
  1) Sort buffers would have records of variable length
  2) Each record in the sort buffer would be stored like
     <sort_key1><sort_key2>....<addon_length><null_bytes><field1><field2>....
     addon_length is the extra bytes that are required to store the variable
     length of addon field across different records.
  3) Changes in rr_unpack_from_buffer and rr_from_tempfile to take into account
     the variable length of records.

Ported  WL#1509 Pack values of non-sorted fields in the sort buffer from
MySQL by Tor Didriksen

This was forgotten in e9de6386

Add mutex protection while we calculate required slave
thread change and create them. Add error handling.

The MDEV-17062 fix in commit c4195305
was omitted.

row_search_idx_cond_check with rowid_filter upon concurrent access to table

This bug has nothing to do with the concurrent access to table. Rather it
concerns queries for which the optimizer decides to employ a rowid filter
when accessing an InnoDB table by a secondary index, but later when
calling test_if_skip_sort_order() changes its mind to access the table by
the primary key.
Currently usage of rowid filters is not supported in InnoDB if the table
is accessed by the primary key. So in this case usage of a rowid filter
to access the table must be prohibited.

followup for 9d18b624

strangely enough it only failed upgrade test on eoan

This bug could happen when both optimizer switches 'mrr' and 'mrr_sort_keys'
are enabled and the optimizer decided to use a rowid filter when
accessing an InnoDB table by a secondary key. With the above setting
any access by a secondary is converted to the rndpos access. In InnoDB the
rndpos access uses the primary key.
Currently usage of a rowid filter within InnoDB engine is not supported
if the table is accessed by the primary key.

Do not use pushed rowid filter if the table is accessed actually by the
primary key. Use the rowid filter outside the egine code instead.

log_group_max_size: is not needed because redo log do not use fil_io() now

Make chown error non-fatal. Just print a warning.