MDEV-11930 Unexpected ER_ERROR_EVALUATING_EXPRESSION warning upon dropping database with a bad table

DBUG_EXECUTE_IF was wrong, it used my_error, but didn't do error=1.

It's not clear what it was actually testing, what it was supposed
to be testing, and what it has to do with bug#43138, so I removed it.

CRYPTO_set_mem_functions() works only until the first allocation is done:
* remove the second CRYPTO_set_mem_functions() call
* check whether the first CRYPTO_set_mem_functions() call worked
* stricter memory checks (==1, not >1, etc)
* as coc_malloc cannot be removed, make the counter a bit cheaper
* only do the check for OpenSSL 1.1 (because of OpenSSL 1.0 bug)

the array only needs to be reallocated if it's smaller
than needed. Being larger is ok.

also: remove a duplicated check (merge error)

don't use thd->query_id check in background purge threads
(it doesn't work, because thd->query_id is never incremented there)
instead use thd->open_tables directly, there can be only one table
there anyway, and this is the table opened by this purge thread.

cannot use unireg_abort() until mutexes are initialized.

On Windows, when tmpdir is not writable, there are only messages
like this:

2017-07-05 14:04:25 3860 [ERROR] InnoDB: Unable to create temporary file; errno: 0

On other platforms, there would be two messages for each failure:

2017-07-05 17:23:02 140436573771648 [ERROR] mysqld: Can't create/write to file '/dev/null/nonexistent/ibaajU4U' (Errcode: 20 "Not a directory")
2017-07-05 17:23:02 140436573771648 [ERROR] InnoDB: Unable to create temporary file; errno: 20

Interval function makes use of Item_row. Item_row did not correctly mark
with_window_func flag according to its arguments. Fix it by making
Item_row aware of this flag.

When using innodb_page_size=16k, InnoDB tables
that were created in MariaDB 10.1.0 to 10.1.20 with
PAGE_COMPRESSED=1 and
PAGE_COMPRESSION_LEVEL=2 or PAGE_COMPRESSION_LEVEL=3
would fail to load.

fsp_flags_is_valid(): When using innodb_page_size=16k, use a
more strict check for .ibd files, with the assumption that
nobody would try to use different-page-size files.

This is a regression caused by
commit bb60a832

srv_shutdown_all_bg_threads(): If os_thread_count indicates that
no threads are running, do not bother checking thread status.
This avoids a crash when InnoDB startup is aborted before
os_aio_init() has been invoked. (os_aio_all_slots_free() would
dereference AIO::s_reads even though it is NULL.)

InnoDB I/O and buffer pool interfaces and the redo log format
have been changed between MariaDB 10.1 and 10.2, and the backup
code has to be adjusted accordingly.

The code has been simplified, and many memory leaks have been fixed.
Instead of the file name xtrabackup_logfile, the file name ib_logfile0
is being used for the copy of the redo log. Unnecessary InnoDB startup and
shutdown and some unnecessary threads have been removed.

Some help was provided by Vladislav Vaintroub.

Parameters have been cleaned up and aligned with those of MariaDB 10.2.

The --dbug option has been added, so that in debug builds,
--dbug=d,ib_log can be specified to enable diagnostic messages
for processing redo log entries.

By default, innodb_doublewrite=OFF, so that --prepare works faster.
If more crash-safety for --prepare is needed, double buffering
can be enabled.

The parameter innodb_log_checksums=OFF can be used to ignore redo log
checksums in --backup.

Some messages have been cleaned up.
Unless --export is specified, Mariabackup will not deal with undo log.
The InnoDB mini-transaction redo log is not only about user-level
transactions; it is actually about mini-transactions. To avoid confusion,
call it the redo log, not transaction log.

We disable any undo log processing in --prepare.

Because MariaDB 10.2 supports indexed virtual columns, the
undo log processing would need to be able to evaluate virtual column
expressions. To reduce the amount of code dependencies, we will not
process any undo log in prepare.

This means that the --export option must be disabled for now.

This also means that the following options are redundant
and have been removed:
	xtrabackup --apply-log-only
	innobackupex --redo-only

In addition to disabling any undo log processing, we will disable any
further changes to data pages during --prepare, including the change
buffer merge. This means that restoring incremental backups should
reliably work even when change buffering is being used on the server.
Because of this, preparing a backup will not generate any further
redo log, and the redo log file can be safely deleted. (If the
--export option is enabled in the future, it must generate redo log
when processing undo logs and buffered changes.)

In --prepare, we cannot easily know if a partial backup was used,
especially when restoring a series of incremental backups. So, we
simply warn about any missing files, and ignore the redo log for them.

FIXME: Enable the --export option.

FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write
a test that initiates a backup while an ALGORITHM=INPLACE operation
is creating indexes or rebuilding a table. An error should be detected
when preparing the backup.

FIXME: In --incremental --prepare, xtrabackup_apply_delta() should
ensure that if FSP_SIZE is modified, the file size will be adjusted
accordingly.

The parameter was recently introduced in
commit dd8474b1
but this test was not adjusted accordingly.

MDEV-12067 flashback does not correcly revert update/replace statements

MDEV-13228 Assertion `n < rec_offs_n_fields(offsets)' failed in rec_get_nth_field_offs upon crash recovery with compressed table

In my preparatory patch for MDEV-12288, there was an off-by-one
array initialization error that affected debug builds.

The POINT data type is being treated just like any other
geometry data type in InnoDB. The fixed-length data type
DATA_POINT had been introduced in WL#6942 based on a
misunderstanding and without appropriate review.
Because of fundamental design problems (such as a
DEFAULT POINT(0 0) value secretly introduced by InnoDB),
the code was disabled in Oracle Bug#20415831 fix.

This patch removes the dead code and definitions that were
left behind by the Oracle Bug#20415831 patch.

Problem
-------
For one-statement contains multiple row events, Flashback didn't reverse the
sequence of row events inside one-statement.

Solution
--------
Using a new array 'events_in_stmt' to store the row events of one-statement,
when parsed the last one event, then print from the last one to the first one.

In the same time, fixed another bug, without -vv will not insert the table_map
into print_event_info->m_table_map, then change_to_flashback_event() will not
execute because of Table_map_log_event is empty.

- Removed some not old, not used build scipts
- Removed tokudb and rocksdb from 32 bit builds
  This enables one now to easily build 32 bit binaries
  on 64 bit systems

There was a missing test in CTE handling if creating a temporary table
failed (in this case as a result of out of space). This caused a table
handler to be used even if it was not allocated.

This is preparation for MDEV-12288, which would set DB_TRX_ID=0
when purging history. Also with that change in place, delete-marked
records must always refer to an undo log record via a nonzero
DB_TRX_ID column. (The DB_TRX_ID is only present in clustered index
leaf page records.)

btr_cur_parse_del_mark_set_clust_rec(), rec_get_trx_id():
Statically allocate the offsets
(should never use the heap). Add some debug assertions.

Replace some use of rec_get_trx_id() with row_get_rec_trx_id().

trx_undo_report_row_operation(): Add some sanity checks that are
common for all operations that produce undo log.

- Crude hack to get it to work. Hope Serg has a better solution at some point..

- Added variable tmp_disk_table_size
- Added variable tmp_memory_table_size as an alias for tmp_table_size
- Changed internal variable tmp_table_size to tmp_memory_table_size
- create_info.data_file_length is now set with tmp_disk_table_size
- Fixed that Aria doesn't reset max_data_file_length for internal tables
- Added status flag if table is full so that we can detect this on next insert.
  This ensures that the table is always 'correct', but we get the error one
  row after the row that grow the table too big.
- Removed some mutex lock for internal temporary tables