if we don't need to print field's table name,
we surely don't need to print field's db name either

Use the correct target name when querying libmariadb.so dependencies.
Filter out linker options (no-undefined and the version script)

remove double-initialization of MYSQL structure

remove ANSI_QUOTES when generating partition syntax for frm

Remove now-unused part_func_string and subpart_func_string
from partition_info.

don't print partitioning expression as it was entered by the user,
use Item::print() according to the sql_mode and sql_quote_show_create

Don't write to a temporary file, use String.
Remove strange one-liner "helpers", use String methods.
Don't use current_thd, don't allocate memory for 1-byte strings, etc.

don't do auditing if thd is NULL.

Collaterals:
* copy-paste bugs server_audit.c
* uninitialized user field when thd in NULL

when opening 10.1- table that has virtual columns:

1. don't error out if it has vcols over autoinc columns.
   just issue a warning.
2. set vcol type properly
3. in innodb: use table->s->stored_fields instead of table->s->fields,
   because that's what was stored in innodb data dictionary

and
MDEV-13144 regexp on views - crashed mariadb server

implement Item_func_regex::build_clone()

use correct type for Alter_inplace_info flags.

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.