Fix a failure in rocksdb_rpl.rpl_rocksdb_2pc_crash_recover test.
Don't do XA with binlog if @@rocksdb_enable_2pc=OFF.

remove remnants of 10.0 bugfix, incorrectly merged into 10.2

Using col_names[i] was obviously, wrong, must've been col_names[ifield->col_no].
incorrect column name resulted in innodb having index unique_id2(id1),
while the server thought it's unique_id2(id4).
But col_names[ifield->col_no] is wrong too, because `table` has non-renamed
columns, so the correct column name is always dict_table_get_col_name(table, ifield->col_no)

$WSREP_SST_OPT_CONF already includes --defaults-extra-file= prefix.

allow to build with the default port number 3306.
Now -DMYSQL_TCP_PORT=# sets the default port name and
-DMYSQL_TCP_PORT_DEFAULT=# sets the magic port=0 behavior,
if it's MYSQL_TCP_PORT_DEFAULT=0 it's enabled, otherwise - disabled.

Use mariadb_config, for C/C config variables

Issue
=====
The original issue was that the size of a fil_per_table tablespace was calculated
incorrectly during truncate in the presence of an fts index. This incorrect calculation
was fixed as part of BUG#25053705 along with a testcase to reproduce the bug. The
assert that was added as part of it to reproduce the bug was wrong and resulted in
this bug.

Fix
===
Although the assert was removed earlier in a seperate commit as it was blocking the
ntest, this patch replaces the other parts of the code that were added to reproduce
the bug and replaces it with code that tries to reproduce the bug in a different way.

The new code basically tries to tweak conditions so as to simulate the random read
where a page that doesn't exist is tried to be read.

RB: 15890
Reviewed-by: Jimmy Yang <Jimmy.Yang@oracle.com>
Reviewed-by: Satya Bodapati <satya.bodapati@oracle.com>

MySQL 5.7 added code to push down the LIMIT to fulltext search
in InnoDB:

commit 2cd0ebf97e1b265e2282d7ceb5d8dfb663ffc48f
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date:   Fri May 27 13:49:28 2016 +0530

    Bug #22709692   FTS QUERY EXCEEDS RESULT CACHE LIMIT

The code was disabled when MySQL 5.7.9 was merged to MariaDB 10.2.2.

We shall remove the disabled code and unnecessary variables.

Port the previous patch:
- Implement MariaDB's Group Commit API. This is a first
   attempt which lacks the expected performance.

To newer MariaDB (which includes newer MyRocks)

fil_mutex_enter_and_prepare_for_io(): Reacquire fil_system->mutex after
failing to close a file and before retrying.

This was a false alarm in a debug check that was introduced in
commit 48192f96 which was a
10.2 code refactoring in preparation for
MDEV-11369 (instant ADD COLUMN) in 10.3.2. The code refactoring
only affected debug builds.

InnoDB B-tree record locks are only supposed to exist on leaf page
records. An assertion failed, because the debug function lock_validate()
was invoking lock_rec_block_validate() on a page for which there were
no locks set in the record lock bitmap. This could happen on a page split.
Especially when the index size grows from a single page to multiple pages,
the root page would transform from a leaf node into an internal node,
and its record lock bitmap would be emptied.

lock_validate(): Skip empty lock bitmaps.

There is no call to os_thread_join(), so we should detach the thread
handles in order to avoid any resource leaks.

Conflicts:
	storage/rocksdb/ha_rocksdb.cc

Problem was that we could take page latches on different
order than wat is entitled with SX-lock. To follow the
latching order defined in WL#6326, acquire index->lock X-latch.
This entitles us to acquire page latches in any order for the index.

btr0btr.cc
	Document latch rules before and after MariaDB 10.2.2

sync0rw.cc
	Document latch compatibility rules better.

btr_defragment_merge_pages
	Fix parameter value.

btr_defragment_thread
	Acquire X-lock to dict_index_t::lock before restoring
	cursor position and continuing defragmentation.

ha_innobase::optimize
	Restore defragment feature.

Testing
	Add GIS-index and FT-index to table being defragmented.

	Defragmentation is not done to GIS-indexes and FT auxiliary
	tables.

A reference to a CTE may occur not in the master of the CTE
specification. In this case if the reference to the CTE is
the first one the specification should be detached from its
master and attached to the referencing select.

Also fixed the TYPE column in the lines of the EXPLAIN output
created for CTE tables.

rdb_sst_info.cc must be compiled with RTTI

Changing Field::set_default from void to int.
It now uses the same return value notation with Field::store*()
and Item::save_in_field().

in 10.1 innodb was basically ignoring virtual columns. In particular,
information about them was not stored in system tables. To make 10.1
table usable in 10.2 it needs to be rebuilt to have virtual colunm
metadata properly recreated.

See also a followup:
MDEV-14046 Allow ALGORITHM=INPLACE for 10.1 tables that contain virtual columns

fil_ibd_create(): commit b731a5bc
introduced a variable that was unused outside Windows. Use it
on all platforms.

btr_store_big_rec_extern_fields(): Remove the unused parameter 'upd'
that was added in https://github.com/mysql/mysql-server/commit/ce0a1e85e24e48b8171f767b44330d
and merged to MariaDB 10.2.2
in commit 2e814d47.

    is_bulk_op())' failed upon altering table with geometry field.

        Tests added.

                    is_bulk_op())' failed upon altering table with geometry field.

        Check for the validity of the DEFAULT value for the
        geometry field.

This fixes some truncation warnings on Win64

Reapply a MySQL 5.6.23/5.7.10 Oracle Bug#20029625 fix that was inadvertently reverted in MariaDB 10.2.2

The fix https://github.com/mysql/mysql-server/commit/716f97e2714e70f35d2dc01f0125ed833c62b408
was inadvertently reverted in
commit 2e814d47
"Merge InnoDB 5.7 from mysql-5.7.9".

Reapply the fix, because the test of the bug would fail
after merging MDEV-13838, which replaced an earlier incorrect
bug fix with a correct one.

Added cstdlib librabry to rdb_datadic.h

of WSREP_TO_ISOLATION_BEGIN.

Mariabackup 10.2.7 would delete the redo log files after a successful
--prepare operation. If the user is manually copying the prepared files
instead of using the --copy-back option, it could happen that some old
redo log file would be preserved in the restored location. These old
redo log files could cause corruption of the restored data files when
the server is started up.

We prevent this scenario by creating a "poisoned" redo log file
ib_logfile0 at the end of the --prepare step. The poisoning consists
of simply truncating the file to an empty file. InnoDB will refuse
to start up on an empty redo log file.

copy_back(): Delete all redo log files in the target if the source
file ib_logfile0 is empty. (Previously we did this if the source
file is missing.)

SRV_OPERATION_RESTORE_EXPORT: A new variant of SRV_OPERATION_RESTORE
when the --export option is specified. In this mode, we will keep
deleting all redo log files, instead of truncating the first one.

delete_log_files(): Add a parameter for the first file to delete,
to be passed as 0 or 1.

innobase_start_or_create_for_mysql(): In mariabackup --prepare,
tolerate an empty ib_logfile0 file. Otherwise, require the first
redo log file to be longer than 4 blocks (2048 bytes). Unless
--export was specified, truncate the first log file at the
end of --prepare.

Use GetFileInformationByHandleEx with FileAttributeTagInfo to query whether
the file is sparse. This saves 1 syscall, as GetFileInformationByHandle()
would additionally query volume info.