Signed-off-by: Sachin Setiya <sachinsetia1001@gmail.com>

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

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.

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

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

Add diagnostics output if any Sphinx components aren't found

The fix for bug mdev-5104 did not take into account that
for any call of setup_order the size of ref_array must
be big enough. This patch fixes this problem.

Memory was leaked when ALTER TABLE is attempted on a table
that contains corrupted indexes.
The memory leak was reported by AddressSanitizer for the test
innodb.innodb_corrupt_bit. The leak was introduced into
MariaDB Server 10.0.26, 10.1.15, 10.2.1 by the following:

commit c081c978
Merge: 1d21b221 a482e76e
Author: Sergei Golubchik <serg@mariadb.org>
Date:   Tue Jun 21 14:11:02 2016 +0200

   Merge branch '5.5' into bb-10.0

The warning is "blocks are still reachable in loss record",
happens in malloc / _dl_close_worker. Suppression added

When the test is run as a part of the suite with valgrind,
only allow it to be executed if --big-test is set.
If the test is run by specifying its name explicitly, it
will still be executed, even with valgrind without big-test,
MTR has special logic for that

The guilty part of the test checks for performance degradation on
a query with numerous joins on an empty table. The test expects
the query to take less than 1 second, and fails if it is not so
(which can happen on very slow builders).

The solution is to add more JOINs to the query. On a fixed server,
it should not have any noticeable impact on the query execution,
while on the unfixed version the query would take several times
longer (e.g. 6.5 sec vs 1.5 sec). Thus, we can increase the margin
for the error, and make the test fail when the query takes longer
than 5 seconds.

- fix the test to avoid false-negatives before MDEV-5114 patch;
- fix the race condition which made the test fail on slow builders