don't check defaults for vcols

Fixing Item::decimal_precision() to return at least one digit.
This fixes the problem reported in MDEV.

Also, fixing Item_func_signed::fix_length_and_dec() to reserve
space for at least one digit (plus one character for an optional sign).
This is needed to have CONVERT(expr,SIGNED) and CONVERT(expr,UNSIGNED)
create correct string fields when they appear in string context, e.g.:
  CREATE TABLE t1 AS SELECT CONCAT(CONVERT('',SIGNED));

Test crash recovery from an encrypted redo log with innodb_encrypt_log=0.
Previously, we did a clean shutdown, so only the log checkpoint
information would have been read from the redo log. With this change,
we will be reading and applying encrypted redo log records.

include/start_mysqld.inc: Observe $restart_parameters.

encryption.innodb-log-encrypt: Remove some unnecessary statements,
and instead of restarting the server and concurrently accessing
the files while the server is running, kill the server, check the
files, and finally start up the server.

innodb.log_data_file_size: Use start_mysqld.inc with $restart_parameters.

Extra merge commit due to intermediate commits pushed to 10.0 while
merge was done.

MDEV-11706 Assertion `is_stat_field || !table || (!table->write_set || bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index)))' failed in Field_time::store_TIME_with_warning

vcols and triggers. Revert 094f4cf7,
backport the correct fix (Table_triggers_list::mark_fields_used() not
marking vcols) from 10.2.

The supplied sql_mode(s) should be converted to ASCII first,
before comparing it with the sql_mode set.

The symbol HAVE_VALGRIND_MEMCHECK_H was never defined.
Instead, the symbol HAVE_VALGRIND should have been used.

compile, and install selinux policy for mysqld_safe_helper on centos6.
the policy was created as described in https://mariadb.com/kb/en/mariadb/what-to-do-if-mariadb-doesnt-start/#other-selinux-changes

buf_flush_init_flush_rbt() was called too early in MariaDB server 10.0,
10.1, MySQL 5.5 and MySQL 5.6. The memory leak has been fixed in
the XtraDB storage engine and in MySQL 5.7.

As a result, when the server is started to initialize new data files,
the buf_pool->flush_rbt will be created unnecessarily and then leaked.
This memory leak was noticed in MariaDB server 10.1 when running the
test encryption.innodb_first_page.

The problem in MariaDB is introduced by this merge commit:
c33db2cd

The merge comes from mysql and the original author comes from this
commit from MySQL:
------------------------------------------------
    commit 160b823d146288d66638e4a740d6d2da72f9a689
    Author: Marc Alff <marc.alff@oracle.com>
    Date:   Tue Aug 30 12:14:07 2016 +0200

    Bug#22551677 SIGNAL 11 IN LF_PINBOX_PUT_PINS

    Backport to 5.6
------------------------------------------------

The breaking change is in start_socket_wait_v1 where instead of using
m_thread_owner, we make use of my_pthread_getspecific_ptr to fetch a
thread local storage value. Unfortunately this invalidates the
"m_thread_owner" member when a socket is created. The internals of the
socket structure have m_thread_owner set to NULL, but when checking for
ownership we actually look at the current thread's key store.

This seems incorrect however it is not immediately apparent why.

To not diverge from MySQL's reasoning as it is not described what the
actual problem was that this commit is trying to fix, I have adjusted the
unittest to account for this new behaviour. We destroy the current
thread in the unit test, such that the newly created socket actually has
no thread owner. The m_thread_owner is untouched in all this.

* Update mysqld_safe script to remove duplicated parameter --crash-script
* Make --core-file-size accept underscores as well as dashes correctly.
* Add mysqld_safe_helper to Debian and Ubuntu files.
* Update innodb minor version to 35

        Have to use 'keyname' to check the name uniqueness.

c3cf7f47 reverted the patch
for BUG#24487120. After merging the reverting patch from MySQL
to MariaDB the problems described in MDEV-11079 and MDEV-11631 disappeared.
Adding test cases only.

Perform a slow shutdown at the start of the test, and create all
InnoDB tables with STATS_PERSISTENT=0, so that any I/O related to
background tasks (change buffer merge, purge, persistent statistics)
should be eliminated.

This should be a non-functional change. I was unable to repeat
MDEV-11626 innodb.innodb-change-buffer-recovery fails for xtradb
and cannot determine the reason for the failure without having access
to the files.

The repeatability of MDEV-11626 should not be affected by these changes.

MDEV-11317: `! is_set()' or `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' fails in Diagnostics_area::set_ok_status on CREATE OR REPLACE with ARCHIVE table

Problem was with deleting non existing .frm file for a storage engine that
doesn't have .frm files (yet)

Fixed by not giving an error for non existing .frm files for storage engines
that are using discovery
Fixed also valgrind supression related to the given test case

Sometimes innodb_data_file_size_debug was reported as INT UNSIGNED
instead of BIGINT UNSIGNED. Make it uint instead of ulong to get
a more deterministic result.

Add <install_root>/data/my.ini to the search path -  this my.ini location
is used since MariaDB 5.2

for the default installation.

It is now defined as "C:/Program Files/MariaDB ${MYSQL_BASE_VERSION}"
which is where installer indeed puts it by default.

It still does not cover every case -32bit installer on 64 bit Windows would put installation
root under  "C:/Program Files (x86)", but better than the path used
previously C:/MariaDB${MYSQL_BASE_VERSION}, which was never correct.

in default installation.

Added plugin-dir to the [client] section of the generated my.ini,
so that  installed services (MSI or mysql_install_db.exe) would be able to
find plugin directory.

MDEV-9084 Calling a stored function from a nested select from temporary table causes unpredictable behavior

Cherry-pick: f4a0af070ce49abae60040f6f32e1074309c27fb
Author: Dmitry Lenev <dmitry.lenev@oracle.com>
Date:   Mon Jul 25 16:06:52 2016 +0300

  Fix for bug #16672723 "CAN'T FIND TEMPORARY TABLE".

  Attempt to execute prepared CREATE TABLE SELECT statement which used
  temporary table in the subquery in FROM clause and stored function
  failed with unwarranted ER_NO_SUCH_TABLE error. The same happened
  when such statement was used in stored procedure and this procedure
  was re-executed.

  The problem occurred because execution of such prepared statement/its
  re-execution as part of stored procedure incorrectly set
  Query_table_list::query_tables_own_last marker, indicating the last
  table which is directly used by statement. As result temporary table
  used in the subquery was treated as indirectly used/belonging to
  prelocking list and was not pre-opened by open_temporary_tables()
  call before statement execution. Thus causing ER_NO_SUCH_TABLE errors
  since our code assumes that temporary tables need to be correctly
  pre-opened before statement execution.

  This problem became visible only in version 5.6 after patches related to
  bug 11746602/27480 "EXTEND CREATE TEMPORARY TABLES PRIVILEGE TO ALLOW
  TEMP TABLE OPERATIONS" since they have introduced pre-opening of temporary
  tables for statements.

  Incorrect setting of Query_table_list::query_tables_own_last happened
  in LEX::first_lists_tables_same() method which is called by CREATE TABLE
  SELECT implementation as part of LEX::unlink_first_table(), which temporary
  excludes table list element for table being created from the query table
  list before handling SELECT part.

  LEX::first_lists_tables_same() tries to ensure that global table list of
  the statement starts with the first table list element from the first
  statement select. To do this it moves such table list element to the head
  of the global table list. If this table happens to be last directly-used
  table for the statement, query_tables_own_last marker is pointing to it.
  Since this marker was not updated when table list element was moved we
  ended up with all tables except the first table separated by it as if
  they were not directly used by statement (i.e. belonged to prelocked
  tables list).

  This fix changes code of LEX::first_lists_tables_same() to update
  query_tables_own_last marker in cases when it points to the table
  being moved. It is set to the table which precedes table being moved
  in this case.

Make the slave SQL thread always output to the error log the message "Slave
SQL thread exiting, replication stopped in ..." whenever it previously
outputted "Slave SQL thread initialized, starting replication ...".

Before this patch, it was somewhat inconsistent in which cases the message
would be output and in which not, depending on the exact time and cause of
the condition that caused the SQL thread to stop.

MTR raises default wait_for_pos_timeout from 300 to 1500 when tests
are run with valgrind. The same needs to be done for other
replication-related waits.

The change should fix one of failures mentioned in MDEV-10653
(rpl.rpl_parallel fails in buildbot with timeout), the one
on the valgrind builder; but not all of them