This form of corruption was only reproduced on MariaDB 10.5.4
after the MDEV-22867 fix was applied in
commit 43120009.

While we do not know how to reproduce this corruption in
MariaDB 10.4, we are applying the code fix without a test case.

btr_cur_pessimistic_update(): Invoke btr_set_instant() if needed.

- Add 'libboost-all-dev' and 'libreadline-gplv2-dev' as they were was found
  to be a compulsory build dependency for columnstore plugin.
- Add 'expect' as run-time dependencey for columnstore plugin as scripts
  use it:
    usr/bin/mcs_module_installer.sh: #!/usr/bin/expect
    usr/bin/remote_command.sh: #!/usr/bin/expect
    usr/bin/remote_command_verify.sh: #!/usr/bin/expect
    usr/bin/remote_scp_get.sh: #!/usr/bin/expect
    usr/bin/remote_scp_put.sh: #!/usr/bin/expect
    usr/bin/rsync.sh: #!/usr/bin/expect
- Properly define depends on Python. No Python 2 support needs to be
  considered, Python 3 has been around long enough. Fixes Lintian errors
    E: mariadb-plugin-columnstore: python-script-but-no-python-dep
    usr/bin/mcs-loadbrm.py #!python
    E: mariadb-plugin-columnstore: python-script-but-no-python-dep
    usr/bin/mcs-start-storagemanager.py #!python
- Partially revert undocumented and thus unjustified changes in commits
  d69a79da63287089efdc5f90a11ecd66ce55b471 and
  c0565666cfe6528b76bc53ce50d3690d13c92cf6.
- Trigger ldconfig, otherwise Lintian complains:
    E: mariadb-plugin-columnstore: package-must-activate-ldconfig-trigger
    usr/lib/x86_64-linux-gnu/libwriteengineredistribute.so
- Update postinst to be compatible with new server binary mariadbd name.
- Properly detect systemd or fallback to sysv init in postrm script.
- Only attempt to build ColumnStore on amd64 and i386. Test builds on
  Launchpad.net showed the CMake plugin configure step will prevent even
  attempts to build on other platforms.
- Clean up and unify cmake build command in debian/rules.
- Explicitly list files not installed.
- Run 'wrap-and-sort -a -v'.
- Truncate build logs on Salsa-CI to keep under 4 MB. This is now needed
  as the ColumnStore build is so verbose.
  See https://jira.mariadb.org/browse/MCOL-4111.
- Update Travis-CI dependencies to match new debian/control.

The auth_pam_tool that is executed from pam_auth() can be still
not finished by the time we do the waitpid() there.
As we use WNOHANG option for the waitpid(), it didn't wait and
left the zombie process. So let's do the loop of waitpid() with the
limited number of sleeps.

../sql/sql_class.cc: In constructor ‘start_new_trans::start_new_trans(THD*)’:
../include/m_string.h:61:49: error: ‘void* memset(void*, int, size_t)’ clearing an object of non-trivial type ‘struct Ha_data’; use assignment or value-initialization instead [-Werror=class-memaccess]
   61 | # define bzero(A,B)             memset((A),0,(B))
      |                                                 ^
../sql/sql_class.cc:5805:3: note: in expansion of macro ‘bzero’
 5805 |   bzero(thd->ha_data, sizeof(thd->ha_data));
      |   ^~~~~
In file included from ../sql/sql_class.cc:33:
../sql/sql_class.h:2003:8: note: ‘struct Ha_data’ declared here
 2003 | struct Ha_data
      |        ^~~~~~~

In mi_check_index_tuple(), when rowid filter check returns
CHECK_OUT_OF_RANGE, set info->lastpos= HA_OFFSET_ERROR, like
it is done above for the ICP check.

Check if we really need the mariadb.sys user

Based on output of 'aria_s3_copy --help'.

Also fix a typo in command help.

1. Do not initialize dict_table_t::stats_latch in ibuf
2. Remove overengineering in GenericPolicy to speed up things

dict_mem_table_create(): add new argument init_stats_latch

ibuf_dummy_index_create(): do not initialize dict_table_t::stats_latch

GenericPolicy: add new members m_filename and m_line

sync_file_create_register()
sync_file_created_deregister()
sync_file_created_get()
CreateTracker: remove

rw_lock_t::created: a new debug member

Remove types casting with a help of virtual functions.

commit ab406990 accidentally
misplaced #endif directives.

The merge commit 0fd89a1a
of commit b6ec1e8b
seems to cause occasional MemorySanitizer failures,
because it failed to replace some MEM_UNDEFINED() calls
with MEM_MAKE_ADDRESSABLE().

my_large_free(): Correctly invoke MEM_MAKE_ADDRESSABLE() after
freeing memory. Failure to do so could cause bogus
AddressSanitizer failures for memory allocated by my_large_malloc().
On MemorySanitizer, we will do nothing.

buf_pool_t::chunk_t::create(): Replace the MEM_MAKE_ADDRESSABLE()
that had been added in commit 48493132
to work around the issue.

commit 48493132 was a necessary
fix for the buffer pool resizing tests in 10.5 in
AddressSanitizer. However, that change would break the tests
innodb.innodb_buffer_pool_resize and
innodb.innodb_buffer_pool_resize_with_chunks
when run in MemorySanitizer, or presumably in Valgrind as well.
(Those tests run "forever" in Valgrind.)

buf_pool_resize(): Cancel the effect of MEM_NOACCESS() in Valgrind
and ASAN. In MSAN, MEM_NOACCESS() is a no-op, and hence we must do
nothing special here.

MEM_MAKE_ADDRESSABLE() would declare the memory contents undefined.
In this particular case, we must actually declare the contents
defined for Valgrind.

Let us avoid any overhead in release builds, for an empty function.

The merge commit 0fd89a1a
of commit b6ec1e8b
was slightly incomplete.

ReadView::mem_valid(): Use the correct primitive
MEM_MAKE_ADDRESSABLE(), because MEM_UNDEFINED() now has
no effect on ASAN.

recv_sys_t::alloc(), recv_sys_t::add(): Use MEM_MAKE_ADDRESSABLE()
instead of MEM_UNDEFINED(), to get the correct behaviour for ASAN.
For Valgrind and MSAN, there is no change in behaviour.

recv_sys_t::free(), recv_sys_t::clear(): Before freeing memory to
buf_pool.free_list, invoke MEM_MAKE_ADDRESSABLE() on the entire
buf_block_t::frame, to cancel the effect of MEM_NOACCESS() in
recv_sys_t::alloc().

first try discovering engines, then the rest.
otherwise every DROP TABLE non_existent; will do
lots of i/o trying to remove .MYI/.MYD/.MAI/.MAD/.CSV/etc files

this matches the old behavior where DROP TABLE always tried to discover
the table before dropping.

normal DROP TABLE with many tables continues after an error,
trying to drop as many tables as possible. But DROP TEMPORARY TABLE
was aborting on the first error. Change it to behave as DROP TABLE does.

don't do table discovery on DROP. DROP falls back to "force"
approach when a table isn't found and will try to drop in all
engines anyway. That is, trying to discover in all engines before
the drop is redundant and may be expensive.

drop-no_root needs DROP DATABASE to fail.
But `chmod 000` is not reliable after drop table force anymore.

Make DROP DATABASE to fail by creating an extra file in the db dir

remove redundant argument, return all possible enum values

minor post-review fixes
* remove duplicate tests
* first file indicates table existance even with discovery
* don't duplicate trigger dropping code

first step in moving drop table out of the handler.
todo: other methods that don't need an open table

for now hton->drop_table is optional, for backward compatibility
reasons