this closes the memory leak, that started to appear after da5c3e03

trx::has_logged_persistent(): Renamed from trx_is_redo_rseg_updated().
Determines if a transaction has generated any persistent undo log.

trx::has_logged(): Renamed from trx_is_rseg_updated().
Determines if a transaction has generated any undo log.

Added CHECK constraints to I_S.TABLE_CONSTRAINTS.
Fixed a bug regarding virtual column definitions whose name is the field name.
Added test case: check_constraint_show

The function Item::split_sum_func2() incorrectly processed the function
items with window functions that were not window functions themselfes
and were used as arguments of other functions.

With the current design the function copy_funcs() should ignore
the items with window functions from the array **func_ptr.

followup for da5c3e03

moved to storage/innobase/

also removed duplicate checks from storage/innobase/CMakeLists.txt
(they're all in storage/innobase/innodb.cmake)

MDEV-11605 Assertion `(longlong) thd->status_var.local_memory_used >= 0 || !debug_assert_on_not_freed_memory' failed in my_malloc_size_cb_func

MyISAM in compute_vcols() - which is used only in mi_check code -
was computing indexed vcols into an internally allocated buffer
(not record[0]) and the buffer was calculated to be long enough to fit
every keyseg (a keyseg knows where its value in a record buffer is
and the length of the value).

This logic didn' work for prefix keys, because the keyseg length is the
length of a prefix, but the record buffer needs to fit the complete
value of a vcol. In this bug MyISAM was writing a 2K varchar
into a buffer too short.

Also it didn't work for repair-with-keycache, because that code
recalculats all vcols, not only indexed ones.

So, the buffer size (MYISAM_SHARE::vreclength) should include all
vcols' full lengths. But it was calculated in mi_open and low-level
MyISAM code has no knowledge of vcols.

As a fix we now recalculate MYISAM_SHARE::vreclength in
ha_myisam::setup_vcols_for_repair() which is always called
before compute_vcols().

MDEV-10354 Assertion `! is_set()' failed in Diagnostics_area::set_ok_status on CREATE TABLE with invalid default

test case

MDEV-11114 Cannot drop column referenced by CHECK constraint: Unknown column 'a' in 'virtual column function'

clarify the error message

add columns needed for CHECK constraints not only to read_set,
but also to vcol_set.

give threads more descriptive names

don't build the server with jemalloc.
only build tokudb with it.
move tokudb into a separate package, because it brings a new dependency

disable XtraDB in a way that makes it impossible to be built

* remove redundant casts
* fix fix_win_paths() not to pretend that it takes const char* string
  because it changes it. Fix its callers not to pass const strings
  into it.
* use _WIN32 not __WIN__

increase stack size for labrador

* add a clarifying comment
* apply /wd4244 /wd4146 to ref10 source files, not to the library

        Added IS_GENERATED and GENERATION_EXPRESSION columns required by
        the SQL standard

The function st_select_lex_unit::exec_recursive() incorrectly determined
that a CTE mutually recursive with some others was stabilized in the case
when the non-recursive part of the CTE returned an empty set. As a result
the server fell into an infinite loop when executing a query using
this CTE.

Do not truncate pointers returned by _findfirst to int.

Mutually recursive CTE could cause a crash of the server in the case
when they were not Standard compliant. The crash happened in
mysql_derived_prepare(), because the destructor the derived_result
object created for a CTE that was mutually recursive with some others
was called twice. Yet this destructor should not be called for resursive
references.

The method With_element::check_unrestricted_recursive() icorrectly performed
the check that no recursive reference is not encountered in inner parts of
outer joins. As a result the server reported errors for valid specifications
with outer joins.

This could fix a race condition between mysqld and perl on Windows.

The test was unnecessarily depending on InnoDB purge, which can
sometimes fail to proceed.

Let us rewrite the test to use BEGIN;INSERT;ROLLBACK to cause the
immediate removal of the desired records.