* add error for truncation of versioned tables: `ER_TRUNCATE_ILLEGAL_VERS`
* make a full table open with `tdc_aquire_share` instead of just `ha_table_exists` check
test suites run: main, parts, versioning

Closes #785

Closes #1212

Fixing a test failure tokudb.change_column_varbin_descriptor

Always initialize dict_sys.m_initialised.

dict_sys.lock(), dict_sys_lock(): Acquire both mutex and latch.

dict_sys.unlock(), dict_sys_unlock(): Release both mutex and latch.

dict_sys.assert_locked(): Assert that both mutex and latch are held.

The magic_n only complicated object destruction and did not serve
any useful purpose.

* Versioning tests support

Closes #1043

handler::write_row() should not destroy the state of the running
index_search/index_next/... or rnd_init/rnd_next/... scan

Closes #677

Improve diagnostics. Try to guess what type user tried to type.

dict_sys_t::create(): Renamed from dict_init().

dict_sys_t::close(): Renamed from dict_close().

dict_sys_t::add(): Sliced from dict_table_t::add_to_cache().

dict_sys_t::remove(): Renamed from dict_table_remove_from_cache().

dict_sys_t::prevent_eviction(): Renamed from
dict_table_move_from_lru_to_non_lru().

dict_sys_t::acquire(): Replaces dict_move_to_mru() and some more logic.

dict_sys_t::resize(): Renamed from dict_resize().

dict_sys_t::find(): Replaces dict_lru_find_table() and
dict_non_lru_find_table().

JSON_MERGE_PATCH implemented. Added JSON_MERGE_PRESERVE as a synonim for
the JSON_MERGE.

Fixed, now server can be configured with eq_range_index_dive_limit set in cnf file

The bug was that when using mysql_list_fields, then
table_list->schema_table_name was not filled in.
Fixed by using table_list->schema_table instead, which is always
filled in.

Fix both code paths:
- Change the test source code so it doesn't cause the "Unused variable"
  warning (which -Werror converted into error and caused CMake not to set
  HAVE_THREAD_LOCAL)

- If the system doesn't seem to support HAVE_THREAD_LOCAL, refuse to
  compile (rather than producing a binary that crashes for some tests)

Originally submitted at https://github.com/facebook/mysql-5.6/pull/905

This test takes ~6 minutes, split it for better parallelism.

Problem:
========
gcc 8 -O2 seems to indicate a real error for this code:

direct_pos= table->file->ha_table_flags() & HA_PRIMARY_KEY_REQUIRED_FOR_POSITION;

the warning: /mariadb/10.4/sql/rpl_gtid.cc:980:7:
warning: 'direct_pos' may be used uninitialized in this function [-Wmaybe-uninitialized]

Analysis:
=========
'direct_pos' is a variable which holds 'table_flags'. If this flag is set it means
that a record within a table can be directly located by using its position. If
this flag is set to '0' means there is no direct access is available, hence
index scan must be initiated to locate the record.  This direct_pos is used to
locate a row within mysql.gtid_slave_pos table for deletion.

Prior to the initialization of 'direct_pos' following steps take place.

1. mysql.gtid_slave_pos table is opened and 'table_opened' flag is set to true.
2. State check for mysql.gtid_slave_pos table is initiated.

If there is a failure during step2 code will be redirected to the error handling
part. This error handling code will access uninitialized value of 'direct_pos'.
This results in above mentioned warning.

Another issue found during analysis is the error handling code uses '!direct_pos'
to identify if the index is initialized or not. This is incorrect.

The index initialization code is shown below.

  if (!direct_pos && (err= table->file->ha_index_init(0, 0)))
    {
      table->file->print_error(err, MYF(0));
      goto end;
    }

In case there is a failure during ha_index_init code will be redirected to end
part which tries to close the uninitialized index. It will result in an assert

10.4/sql/handler.h:3186: int handler::ha_index_end(): Assertion `inited==INDEX'
failed.

Fix:
===
Introduce a new variable named 'index_inited'. Set this variable upon successful
initialization of index initialization otherwise by default it is false. Use
this variable during error handling.

Use thd_get_ha_data()/thd_set_ha_data() which protect against plugin
removal until it has THD ha_data.

Do not reset THD ha_data in rocksdb_close_connection(), cleaner approach
is to let ha_close_connection() do it.

Removed transaction objects cleanup from rocksdb_done_func(). As we lock
plugin properly, there must be no transaction objects during RocksDB
shutdown.

This patch fixes:

- MDEV-19284 INSTANT ALTER with ucs2-to-utf16 conversion produces bad data
- MDEV-19285 INSTANT ALTER from ascii_general_ci to latin1_general_ci produces corrupt data

These regressions were introduced in 10.4.3 by:
- MDEV-15564 Avoid table rebuild in ALTER TABLE on collation or charset changes

Changes:

1. Cleanup: Adding a helper method
   Field_longstr::csinfo_change_allows_instant_alter(),
   to remove some duplicate code in field.cc.

2. Cleanup: removing Type_handler::Charsets_are_compatible() and static
   function charsets_are_compatible() and
   introducing new methods in the recently added class Charset instead:
   - encoding_allows_reinterpret_as()
   - encoding_and_order_allow_reinterpret_as()

3. Bug fix: Removing the code that allowed instant conversion for
   ascii-to->8bit and ucs2-to->utf16.
   This actually fixes MDEV-19284 and MDEV-19285.

4. Bug fix: Adding a helper method Charset::collation_specific_name().
   The old corresponding code in Type_handler::Charsets_are_compatible()
   was not safe against (badly named) user-defined collations whose
   character set name can be longer than collation name.

row_build_spatial_index_key(): Return early if the column is missing
in the table row tuple.

This is a regression that was introduced by
commit 0e5a4ac2.

The bug was introduced in MariaDB 10.4.0 by
commit 0e5a4ac2
but it is good to have a regression test for this scenario
in all applicable MariaDB versions.

Cover the purge of an undo log record that was written before
the completion of ADD SPATIAL INDEX.

Step #2: "[ORDER BY ...] LIMIT n" should not prevent EXISTS-to-IN
conversion, as long as
- the LIMIT clause doesn't have OFFSET
- the LIMIT is not "LIMIT 0".

Step 1: Removal of ORDER BY [LIMIT] from the subquery should be done
earlier and for broader class of subqueries.

The rewrite was done in Item_in_subselect::select_in_like_transformer(),
but this had problems:
- It didn't cover EXISTS subqueries
- It covered IN-subqueries, but was done after the semi-join transformation
  was considered inapplicable, because ORDER BY was present.

Remaining issue:
- EXISTS->IN transformation happens before
  check_and_do_in_subquery_rewrites() is called, so it is still prevented
  by the present ORDER BY.

we had the statistics tables in the FROM list of the select.
The statistics for tables are not read in such cases, so we need
to check this case separately.