This is a port of dveeden's work:

https://github.com/dveeden/mysql-server/commit/e9d00e859e3854bf8f71873caa69c060e670350b

(Mostly changes in linenumbers, a bit of whitespace fix-up.)

- foreign_keys: adjusted according to code changes;
- type_spatial: adjusted according to code changes;
- type_spatial_indexes (for MyISAM): disabled till MDEV-8675 is fixed

Added MTR suppressions for database corruption that is intentionally
caused in test.

Restored self-initialization version of UNINIT_VAR() for all gcc versions.
Fixed UNINIT_VAR() usage: it is supposed to be used along with declaration.

- Added mem_root to all calls to new Item
- Added private method operator new(size_t size) to Item to ensure that
  we always use a mem_root when creating an item.

This saves use once call to current_thd per Item creation

Added mandatory thd parameter to Item (and all derivative classes) constructor.
Added thd parameter to all routines that may create items.
Also removed "current_thd" from Item::Item. This reduced number of
pthread_getspecific() calls from 290 to 177 per OLTP RO transaction.

- UNINIT_VAR() was required for 4.8.3 on openSUSE 13.2

Ensure that fields declared with NOT NULL doesn't have DEFAULT values if not specified and if not timestamp or auto_increment

In original code, sometimes one got an automatic DEFAULT value in some cases, in other cases not.

For example:
create table t1 (a int primary key)      - No default
create table t2 (a int, primary key(a))  - DEFAULT 0
create table t1 SELECT ....              - Default for all fields, even if they where defined as NOT NULL
ALTER TABLE ... MODIFY could sometimes add an unexpected DEFAULT value.

The patch is quite big because we had some many test cases that used
CREATE ... SELECT or CREATE ... (...PRIMARY KEY(xxx)) which doesn't have an automatic DEFAULT anymore.

Other things:
- Removed warnings from InnoDB when waiting from semaphore (got this when testing things with --big)

Issue was two fold (both in MyISAM and Aria)
- optimize and repair failed if there was an old .TMM file around. As optimized and repair are protected against multiple execution, I decided to change so that we just truncate the file if it exists.
- I had missed to check for error condition if creation of the temporary index file failed. This caused the strange behaviour that it looked as if optimized would have worked once.

MDEV-7649 wrong result when comparing utf8 column with an invalid literal
This is a preparatory patch for:
MDEV-8433 Make field<'broken-string' use indexes

This is a pre-requisite patch for:
- MDEV-8433 Make field<'broken-string' use indexes
- MDEV-8625 Bad result set with ignorable characters when using a prefix key
- MDEV-8626 Bad result set with contractions when using a prefix key

Analysis: Problem was that when a new tablespace is created a default
encryption info is also created and stored to the tablespace. Later a
new encryption information was created with correct key_id but that
does not affect on IV.

Fix: Push encryption mode and key_id to lower levels and create
correct encryption info when a new tablespace is created.

This fix does not contain test case because, currently incorrect
encryption key causes page corruption and a lot of error messages
to error log causing mtr to fail.

MDEV-8591: Database page corruption on disk or a failed space, Assertion failure in file buf0buf.cc line 2856 on querying a table using wrong default encryption key

Improved error messaging to show based on original page before
encryption is page maybe encrypted or just corrupted.

Fixing misleading comments in String_copiers::well_formed_copy().

methods in Item_bool_func descendants, which gives some advantages:
- Removing the "bool inv" parameter, as its now available through "this"
  for Item_func_between and Item_func_in, and is not needed for the other
  Item_func_xxx.
- Removing casts
- Making a step to data types plugings

Its initialization in Item_func_xxx::get_mm_tree() is redundant:
the pointer to the current function is passed to get_mm_tree() anyway.

While sql_bin_log=1(0) is meant to control binary logging for the
current session so that the updates to do(not) get logged into the
binary log to be replicated to the async MariaDB slave. The same
should not affect galera replication.

That is, the updates should always get replicated to other galera
nodes regardless of sql_bin_log's value.

Fixed by making sure that the updates are written to binlog cache
irrespective of sql_bin_log.

Added test cases.

Analysis: Handler used table flag HA_REQUIRE_PRIMARY_KEY but a bug on
sql_table.cc function mysql_prepare_create_table internally marked
secondary key with NOT NULL colums as unique key and did not then
fail on requirement that table should have primary key or unique key.

Analysis: Handler table flag HA_REQUIRE_PRIMARY_KEY alone is not enough
to force primary or unique key, if table has at least one NOT NULL
column and secondary key for that column.

Fix: Add additional check that table really has primary key or
unique key for InnoDB terms.

Removed extra line break.

MDEV-8409: Changing file-key-management-encryption-algorithm causes crash and no real info why

Analysis: Both bugs has two different error cases. Firstly, at startup
when server reads latest checkpoint but requested key_version,
key management plugin or encryption algorithm or method is not found
leading corrupted log entry. Secondly, similarly when reading system
tablespace if requested key_version, key management plugin or encryption
algorithm or method is not found leading buffer pool page corruption.

Fix: Firsly, when reading checkpoint at startup check if the log record
may be encrypted and if we find that it could be encrypted, print error
message and do not start server. Secondly, if page is buffer pool seems
corrupted but we find out that there is crypt_info, print additional
error message before asserting.

This bug is essentially another variant of MDEV-7458.

If a transaction conflict caused a deadlock kill of T2 in record_gtid()
during commit, the code would do a rollback _before_ running
rgi->unmark_start_commit(). This creates a race where following transactions
could start too early (before T2 has completed its transaction retry). This
in turn could lead to replication failure, if there was a conflict that
caused eg. duplicate key error or similar.

The fix is to remove these rollbacks (in Query_log_event::do_apply_event()
and Xid_log_event::do_apply_event(). They seem out-of-place; code in
log_event.cc generally does not roll back on error, this is handled higher
up.

In addition, because of the extreme difficulty of reproducing bugs like
MDEV-7458 and MDEV-8302, this patch adds some extra precations to try to
detect (in debug builds) or prevent (in release builds) similar bugs.
ha_rollback_trans() will now call unmark_start_commit() if needed (and
assert in debug build when a caller does rollback without unmark first).

We also add an extra check for thd->killed() so that we avoid doing
mark_start_commit() if we already have a pending deadlock kill.

And we add a missing unmark_start_commit() call in the error case, found by
the above assertion.

Attempting to kill query owned by different user now returns better error:
"You are not owner of query N" instead of "You are not owner of thread N".