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.

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

- 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

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()

- 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.

MDEV-5789: race between rpl_parallel_change_thread_count and slave start upon server start without --skip-slave-start

Make sure to signal the condition variable for the thread pool after
the new threads have been added to the pool.

Thanks to user nanyi607rao, who reported this bug on maria-developers@.

When an rpl_group_info object was returned from the free list, the
rgi->deferred_events_collecting and rgi->deferred_events was not correctly
re-inited. Additionally, the rgi->deferred_events was incorrectly freed in
free_rgi(), which causes unnecessary malloc/free (or crash when re-init is not
done).

Thanks to user nanyi607rao, who reported this bug on maria-developers@.

This constant uses my_time.h, which inclusion is not desirable in nt_servc.cc

Reduced number of my_hash_sort_bin() calls from 4 to 1 per query.
Reduced number of memory accesses done by my_hash_sort_bin().

Details:
- let MDL subsystem use pre-calculated hash value for hash
  inserts and deletes
- let table cache use pre-calculated MDL hash value
- MDL namespace is excluded from hash value calculation, so that
  hash value can be used by table cache as is
- hash value for MDL is calculated as resulting hash value + MDL
  namespace
- extended hash implementation to accept user defined hash function

- MariaDB-5.5 part of the fix: since we can't easily fix query optimization for I_S tables, 
  run the affected-tablespaces query with semijoin=off. It happens to have a good query plan
  with that setting.
[This is a forward-port to MariaDB 10.0]

Patch from Tomas Matejicek

Add missing error code to is_networ_error(), to allow slave to
automatically attempt reconnection also in this case.

- Removed double call to trans_begin() for GTID BEGIN event
- Don't set OPTION_BEGIN before calling trans_begin() as this causes extra work in trans_begin()

sql/log_event.cc:
  Removed double call to trans_begin for GTID BEGIN event.
  Don't set OPTION_BEGIN before calling trans_begin() as this causes extra work in trans_begin().
  This was done by removing parsing of "BEGIN" and instead executing trans_begin() direct.
  This is much faster, but we lost the ability logging of possible slow "BEGIN" statements. As this should never happen it can be ignored.