- Part#2: call HA_EXTRA_FLUSH for the correct handler object, and call it after every change
  (ha_write_row, ha_update_row, ha_delete_row).

- Do like sp.cc does with mysql.proc table: call HA_EXTRA_FLUSH after we've modified
  a statistical table.

Analysis: This was merge error on file fil0fil.cc. fil_system mutex was taken twice because of this.

Fix: Remove unnecessary mutex_enter and fixed the issue with slow posix_fallocate usage.

- If an UPDATE 1) modifies the key it is using, and 2) has ORDER BY ... LIMIT
  which matches the key it is using,  Then we should use "Using buffer", not
  "Using filesort". 

- Adopt MySQL's fix: don't run index_merge optimizer if the table statistics 
  reports that the table has 0 rows.

MDEV-5819: MySQL Bug #13500371 63704: CONVERSION OF '1.' TO A NUMBER GIVES ERROR 1265 (WARN_DATA_TRUNCATED)

Fix by MySQL ported

Automatic merge, except for server_audit.cc that had to be modified slightly
Changes to xtradb and innobase where ignored was these made no sence for 10.0

Fixed max_length of dynamic columns json/create/add functions.

mysql-test/r/create_or_replace.result:
  Added test of releasing of metadata locks
mysql-test/t/create_or_replace.test:
  Added test of releasing of metadata locks
sql/handler.h:
  Added marker if table was deleted as part of CREATE OR REPLACE
sql/sql_base.cc:
  Added Locked_tables_list::unlock_locked_table()
sql/sql_class.h:
  New prototypes
sql/sql_insert.cc:
  Unlock metadata locks for deleted table in case of error. Also do unlock tables if this was the only locked table.
sql/sql_table.cc:
  Unlock metadata locks for deleted table in case of error. Also do unlock tables if this was the only locked table.

Remove memory warnings if mysql client aborts early
Changed copyright for clients

client/mysql.cc:
  Free memory if get_options fails, so that we don't get warnings from safemalloc
include/welcome_copyright_notice.h:
  Added SkySQL to client copyrights
mysql-test/valgrind.supp:
  Added suppressions for memory leaks from dlopen() for OpenSUSE 12.3
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.result:
  Suppress warning
storage/oqgraph/mysql-test/oqgraph/regression_mdev5744.test:
  Suppress warning

meaning of the count, and to remove the alpha warning.

MDEV-5804: If same GTID is received on multiple master connections in multi-source replication, the event is double-executed causing corruption or replication failure

Some fixes, mainly to make it work in non-parallel replication mode also
(--slave-parallel-threads=0).

Patch should be fairly complete now.

extra/replace.c:
  Removed compiler warning
sql/unireg.cc:
  Removed compiler warning
storage/maria/ma_blockrec.c:
  Removed compiler warning
storage/maria/ma_dynrec.c:
  Fixed compiler failure
storage/maria/ma_unique.c:
  Removed compiler warning
storage/myisam/mi_check.c:
  Removed compiler warning
storage/myisam/mi_checksum.c:
  Removed compiler warning

Fixed MDEV-5724 "Server crashes on SQL select containing more group by and left join statements using innodb tables"
  
The problem was that a big record was allocated on the stack, which casued stack to run out.
  
Fixed by using my_safe_alloca() instead of my_alloca() when allocating records.
Now only records <= 16384 are allocated on the stack.

mysql-test/r/stack-crash.result:
  Added test case
mysql-test/t/stack-crash.test:
  Added test case
storage/maria/ma_blockrec.c:
  Use my_safe_alloca() instead of my_alloca()
storage/maria/ma_dynrec.c:
  Use my_safe_alloca() instead of my_alloca()
storage/maria/maria_def.h:
  Added MARIA_MAX_RECORD_ON_STACK
storage/maria/maria_pack.c:
  Use my_safe_alloca() instead of my_alloca()

MDEV-5804: If same GTID is received on multiple master connections in multi-source replication, the event is double-executed causing corruption or replication failure

Before, the arrival of same GTID twice in multi-source replication
would cause double-apply or in gtid strict mode an error.

Keep the behaviour, but add an option --gtid-ignore-duplicates which
allows to correctly handle duplicates, ignoring all but the first.
This relies on the user ensuring correct configuration so that
sequence numbers are strictly increasing within each replication
domain; then duplicates can be detected simply by comparing the
sequence numbers against what is already applied.

Only one master connection (but possibly multiple parallel worker
threads within that connection) is allowed to apply events within
one replication domain at a time; any other connection that
receives a GTID in the same domain either discards it (if it is
already applied) or waits for the other connection to not have
any events to apply.

Intermediate patch, as proof-of-concept for testing. The main limitation
is that currently it is only implemented for parallel replication,
@@slave_parallel_threads > 0.

thread IDs

- Backport testcase from mysql-5.6

- Backport testcase from mysql-5.6

- Backport the testcase from mysql-5.6

- Backport testcase from mysql-5.6

my_atomic_load() is implemented as __sync_fetch_and_or(var, 0) which
writes or-ed value back to var. Memory writes as such have worse
performance and scalability than reads.

gcc 4.7 and up offers better facility for atomic loads/stores. Use it
whenever it is available.

before that, which caused indeterministic outcome

Fixed MDEV-5724 "Server crashes on SQL select containing more group by and left join statements using innodb tables"

The problem was that a big record was allocated on the stack, which casued stack to run out.

Fixed by using my_safe_alloca() instead of my_alloca() when allocating records.
Now only records <= 16384 are allocated on the stack.

mysql-test/r/stack-crash.result:
  Added test case
mysql-test/t/stack-crash.test:
  Added test case
storage/maria/ma_blockrec.c:
  Use my_safe_alloca() instead of my_alloca()
storage/maria/ma_dynrec.c:
  Use my_safe_alloca() instead of my_alloca()
storage/maria/maria_def.h:
  Added MARIA_MAX_RECORD_ON_STACK
storage/maria/maria_pack.c:
  Use my_safe_alloca() instead of my_alloca()

The issue was that create...trigger part of the test suite used a debug_sync point that before was never triggered (in other words, wrong meaningless test).
With the new create ... replace code the debug sync point is triggered and the test case could not handled that.

I fixed this by adding a wait and go for the debug syncpoint in the test.

Removed some compiler warnings from mysql_cond_timedwait


include/mysql/psi/mysql_thread.h:
  Removed compiler warnings
mysql-test/r/create-big.result:
  New test result
mysql-test/t/create-big.test:
  Fixed test case as create_table_select_before_check_if_exists was not before triggered by the code.