buf_dblwr_create(): Remove a bogus check for the buffer pool size.
Theoretically, there is no problem if the doublewrite buffer is
larger than the buffer pool. It could only cause trouble on crash
recovery, and on recovery the doublewrite buffer is read to a buffer
that is allocated outside of the buffer pool. Moreover, this check
was only performed when the database was initialized for the first
time.

On a normal startup, buf_dblwr_init() would not enforce any
rule on the innodb_buffer_pool_size.

Furthermore, in case of an error, commit the mini-transaction in order
to avoid an assertion failure on shutdown. Yes, this will leave the
doublewrite buffer in a corrupted stage, but the doublewrite buffer
should only be initialized when the data files are being initialized
from the scratch in the first place.

buf_load(): When the file cannot be opened for reading, issue a note,
not an error message.

debug build with older cmake.

The constant is implicitely defined by VS when chosen C runtime is Debug
(/MTd, MDd).

CMake does not define it since https://public.kitware.com/Bug/view.php?id=15777
was fixed.

We remove it from compile flags, to be able to build Debug with /MT runtime
using older cmakes.

Also  do not use BUILD_BYPRODUCTS in ExternalPeoject for older cmake

The patch actually fixes the old defect of the optimizer that
could not extract keys for range access from IN predicates
with row arguments.

This problem was resolved in the mysql-5.7 code. The patch
supersedes what was done there:
 - it can build range access when not all components of
 the first row argument are refer to the columns of the table
 for which the range access is constructed.
 - it can use equality predicates to build range access
 to the table that is not referred to in this argument.

Also, some MDEV-11738/MDEV-11581 post-push fixes.

In MariaDB 10.1, there is no fil_space_t::is_being_truncated field,
and the predicates fil_space_t::stop_new_ops and fil_space_t::is_stopping()
are interchangeable. I requested the fil_space_t::is_stopping() to be added
in the review, but some added checks for fil_space_t::stop_new_ops were
not replaced with calls to fil_space_t::is_stopping().

buf_page_decrypt_after_read(): In this low-level I/O operation, we must
look up the tablespace if it exists, even though future I/O operations
have been blocked on it due to a pending DDL operation, such as DROP TABLE
or TRUNCATE TABLE or other table-rebuilding operations (ALTER, OPTIMIZE).
Pass a parameter to fil_space_acquire_low() telling that we are performing
a low-level I/O operation and the fil_space_t::is_stopping() status should
be ignored.

Met additional issues while trying to enable it.

information_schema. Added .opt file to enable running this
test as a part of innodb_zip suite and recorded current
correct results.

- Also rename plugin's config file
- And fix unit test's CMakeLists.txt

Copy the detection logic from 'rocksdb' test suite, add a note.

Merge branch 'bb-10.2-mariarocks-wlad' of https://github.com/mariadb/server into bb-10.2-mariarocks-wlad

Default to static release (previously static debug was used in debug
builds, but not is appears to be too slow)

Restore MYSQL_SYSVAR_UINT64_T and MYSQL_SYSVAR_SIZE_T in
plugin.h

They use much more disk space than all other tests in rocksdb test suite

Don't use Perl autodie module as there are platforms where it is not present

fixes many test failures in optimized builds in --ps-protocol

vcols in the table definition are intentionaly bad and produce
warnings when a table is opened. In some cases (depending on the
TDC/TC state as left by earlier tests) a table might be opened in the
middle of the test, resulting in spurious warnings. Suppress them.

Also, don't run main.mdev-504 for ps-protocol at all (instead of
disabling ps-protocol inside the test, but still running the test)

as a plugin can be disabled, so the target doesn't necessarily exist

parse CHECK constraint *before* Column_definition validity checks

Default to static release (previously static debug was used in debug
builds, but not is appears to be too slow)

We are hitting this
https://github.com/facebook/mysql-5.6/issues/569
and we are not ready to merge the fix currently