(See MDEV-7440 Build fails in libgroonga on Solaris)

MDEV-8082 ON UPDATE is not preserved by CREATE TABLE .. SELECT

-LONGLONG_MIN is the undefined behavior in C.
longlong2decimal() used to do this:

  int longlong2decimal(longlong from, decimal_t *to) {
    if ((to->sign= from < 0))
      return ull2dec(-from, to);
    return ull2dec(from, to);

and later in ull2dec() (DIG_BASE is 1000000000):

  static int ull2dec(ulonglong from, decimal_t *to) {
    for (intg1=1; from >= DIG_BASE; intg1++, from/=DIG_BASE) {}

this breaks in gcc-5 at -O3. Here ull2dec is inlined into
longlong2decimal. And gcc-5 believes that 'from' in the
inlined ull2dec is always a positive integer (indeed, if it was
negative, then -from was used instead). So gcc-5 uses
*signed* comparison with DIG_BASE.

Fix: make a special case for LONGLONG_MIN, don't negate it

MDEV-8045 Assertion `0' fails in Protocol::end_statement on CREATE VIEW after another connection aborted

0 is a valid value for a file descriptor

On EOF vio_read returns 0, it's not an error so the errno
is not reset. If the previous error was EINTR the client
will loop forever. See also man recv.

Merge branch 'openquery:mdev-7781-allow-install-uninstall-plugins-during-bootstrap' into 10.0
Undo MySQL fix for bug#46261

Merge branch 'openquery:mdev-7390-alter-online-table-xx-possible-10.0' into 10.0

Merge branch 'pastcomputer:10.0-oqgraph-6282-6345-6784-test' into 10.0

And don't ignore SSL_CTX_set_tmp_dh() failures

change openssl_1 test not to use non-FIPS ciphers

MDEV-7695 MariaDB - ssl - fips: can not connect with --ssl-cipher=DHE-RSA-AES256-SHA - handshake failure

Change 512bit DH key to 1024bit to meet FIPS requirements

Tell OpenSSL to use MD5 even if FIPS prohibits it.
This is fine as long as we do not use MD5 for cryptographical
purposes (md5 is used internally for P_S message digests and for view
checksums)

MDEV-7697 Client reports ERROR 2006 (MySQL server has gone away) or ERROR 2013 (Lost connection to MySQL server during query) while executing AES* functions under SSL

Clear OpenSSL error queue after an error in AES_ENCRYPT/AES_DECRYPT.
Otherwise it might affect current ssl-encrypted connection.

1. After a period of wait (where last_master_timestamp=0)
   do NOT restore the last_master_timestamp to the timestamp
   of the last executed event (which would mean we've just
   executed it, and we're that much behind the master).

2. Update last_master_timestamp before executing the event,
   not after.

Take the approach from the this commit (but with a different test
case that actually makes sense):

commit 0c75ab453fb8c5439576af8fe5add7a1b89f1569
Author: Luis Soares <luis.soares@sun.com>
Date:   Thu Apr 15 17:39:31 2010 +0100

    BUG#52166: Seconds_Behind_Master spikes after long idle period

which failed main.features test in embedded, because
status variables were not sorted

(to help 'git diff' show the correct function for hunks)

The issue comes from not taking all possibilities to match an entry
within the roles_mapping HASH, when updating the data structure.

MDEV-7038 Assertion `status_var.memory_used == 0' failed in THD::~THD() on disconnect after executing EXPLAIN for multi-table UPDATE

Added test case that caught this bug. It is no longer reproducible in
the current tree.

Problem was that std::vector was allocated using calloc instead of
new, this caused vector constructor not being called and vector
metadata not initialized.

This no-op of an operations should be able to occur without locks and
occur online.

Backport into 10.0

The slave SQL thread was clearing serial_rgi->thd before deleting
serial_rgi, which could cause access to NULL THD.

The clearing was introduced in commit
2e100cc5 and is just plain wrong. So revert
that part (single line) of that commit.

Thanks to Daniel Black for bug analysis and test case.

MDEV-7130: MASTER_POS_WAIT(log_name,log_pos,timeout,"connection_name") hangs, does not respect the timeout

Changed also arg_count check for connection_name to prevent same bug
if fifth argument is introduced in future

MDEV-8031: Parallel replication stops on "connection killed" error (probably incorrectly handled deadlock kill)

There was a rare race, where a deadlock error might not be correctly
handled, causing the slave to stop with something like this in the error
log:

150423 14:04:10 [ERROR] Slave SQL: Connection was killed, Gtid 0-1-2, Internal MariaDB error code: 1927
150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
150423 14:04:10 [Warning] Slave: Deadlock found when trying to get lock; try restarting transaction Error_code: 1213
150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
150423 14:04:10 [Warning] Slave: Connection was killed Error_code: 1927
150423 14:04:10 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'master-bin.000001 position 1234

The problem was incorrect error handling. When a deadlock is detected, it
causes a KILL CONNECTION on the offending thread. This error is then later
converted to a deadlock error, and the transaction is retried.

However, the deadlock error was not cleared at the start of the retry, nor
was the lingering kill signal. So it was possible to get another deadlock
kill early during retry. If this happened with particular thread
scheduling/timing, it was possible that the new KILL CONNECTION error was
masked by the earlier deadlock error, so that the second kill was not
properly converted into a deadlock error and retry.

This patch adds code that clears the old error and killed flag before
starting the retry. It also adds code to handle a deadlock kill caught in a
couple of places where it was not handled before.

Fix a silly typo that caused the test to occasionally fail.

This was a regression from the patch for MDEV-7668.

A test was incorrect, so the slave would not properly handle re-using
temporary tables, which lead to replication failure in this case.

Add some suppressions that were missing. They are for if a STOP SLAVE is
executed early during IO thread startup, when it is negotiating with the
master. The master connection may be killed in the middle of a
mysql_real_query(), which is not a test failure if it is a network error.

This also caught one real code error, fixed with this commit: The I/O thread
would fail to automatically reconnect if a network error happened while
fetching the value of @@GLOBAL.gtid_domain_id.

Conflicts:
	sql/sql_base.cc

MDEV-7936: Assertion `!table || table->in_use == _current_thd()' failed on parallel replication in optimistic mode

Make sure that in parallel replication, we execute wait_for_prior_commit()
before setting table->in_use for a temporary table. Otherwise we can end up
with two parallel replication worker threads competing with each other for
use of a temporary table.

Re-factor the use of find_temporary_table() to be able to handle errors
in the caller (as wait_for_prior_commit() can return error in case of
deadlock kill).

MDEV-7668: Intermediate master groups CREATE TEMPORARY with INSERT, causing parallel replication failure

[This commit cherry-picked to be able to merge MDEV-7936, of which it
is a pre-requisite, into both 10.0 and 10.1.]

Parallel replication depends on locking (table locks, row locks, etc.) to
prevent two conflicting transactions from running and committing in parallel.
But temporary tables are designed to be visible only to one thread, and have
no such locking.

In the concrete issue, an intermediate master could commit a CREATE TEMPORARY
TABLE in the same group commit as in INSERT into that table. Thus, a
lower-level master could attempt to run them in parallel and get an error.

More generally, we need protection from parallel replication trying to run
transactions in parallel that access a common temporary table.

This patch simply causes use of a temporary table from parallel replication
to wait for all previous transactions to commit, serialising the replication
at that point.

(A more fine-grained locking could be added later, possibly. However,
using temporary tables in statement-based replication is in any case
normally undesirable; for example a restart of the server will lose
temporary tables and can break replication).

Note that row-based replication is not affected, as it does not do any
temporary tables on the slave-side.

This patch also cleans up the locking around protecting the list of
temporary tables in Relay_log_info. This used to take the
rli->data_lock at the end of every statement, which is very bad for
concurrency. With this patch, the lock is not taken unless temporary
tables (with statement-based binlogging) are in use on the slave.

Fix a race in the test case. When we do start_slave.inc immediately
followed by stop_slave.inc, it is possible to kill the IO thread while
it is still running inside get_master_version_and_clock(), and this
gives warnings in the error log that cause the test to fail.