When a new master is provisioned that does not have any old binlogs,
the @@gtid_slave_pos is used to know where in the GTID history the
provisioning happened. A slave is allowed to connect at the point of
this value of @@gtid_slave_pos, even if that GTID is not in the
binlogs on the new master.

The code to handle this case when the binlog on the newly provisioned
master is completely empty was just wrong (couple of typos). Clearly it
had never been tested ... :-/

When a new master is provisioned that does not have any old binlogs,
the @@gtid_slave_pos is used to know where in the GTID history the
provisioning happened. A slave is allowed to connect at the point of
this value of @@gtid_slave_pos, even if that GTID is not in the
binlogs on the new master.

But --gtid-strict-mode did not correctly handle this case. When strict
mode was enabled, an attempt to connect at the position would cause an
error about holes in the binlog, which is not correct.

This patch adds a hash of GTIDs that need to be treated specially by
GTID strict mode to deal correctly with this case.

Based on James Briggs contribution.

INFORMATION_SCHEMA.LOCALES plugin.
Contribution by Roberto Spadim 

The test did RESET MASTER and then tried to use --sync_with_master
to wait for GTID-based replication to catch up. This though has
a race, there is a small window where the _old_ pre-RESET MASTER
position on the slave is higher than the new pos-RESET MASTER
position, causing the --sync_with_master to be a no-op.

Fix by using include/wait_condition.inc instead.

When we load the slave state from the mysql.gtid_slave_pos at server start, we
need to load all the rows into the in-memory hash, not just the most recent
one in each replication domain. Otherwise we accumulate cruft in the form of
old rows each time the server restarts.

In record_gtid(), too many rows were deleted from the slave position
hash - we need to always keep on to the most recent committed row,
so we have a valid slave position at all times.

Fix wrong type for sub_id, which would cause overflow grief on
long-running server. Also some related renames for consistency.

Implement discovery of table non-existence, and related changes:

1. Split GTS_FORCE_DISCOVERY (that was meaning two different things in
two different functions) into GTS_FORCE_DISCOVERY and GTS_USE_DISCOVERY.
2. Move GTS_FORCE_DISCOVERY implementation into open_table_def().
3. In recover_from_failed_open() clear old errors *before* discovery,
not after successful discovery. The final error should come
from the discovery.
4. On forced discovery delete table .frm first. Discovery will write
a new one, if desired.
5. If the frm file exists, but not the table in the engine, force
rediscovery if the engine supports it.

mark the SEQUENCE engine as both SBR and RBR capable :)

implement a non-dummy discover_table_existence() method

1. default db type for partitions was stored as 1-byte DB_TYPE code,
   which doesn't work for dynamically generated codes.
2. storage engine plugin for default db type wasn't locked at all,
   which could trivially crash for dynamic plugins.

Now the storage engine name is stored in the extra2 section,
and the plugin is correctly locked.

Remove few ifdef's

1. DROP DATABASE should use ha_discover_table_names(), not look at .frm files.
2. filename_to_tablename() also encodes temp file names #sql- -> #mysql50##sql
3. no special treatment for #sql- files, no TABLE_LIST::internal_tmp_table
4. discover also table file names, that start from #

Minor modification to trigger buildbot.

Now whenever we reach the GTID point requested from the slave (when using GTID
position to connect), we send a fake Gtid_list event. This event is used by
the slave to know the current old-style position for MASTER_POS_WAIT(), and
later the similar binlog position for MASTER_GTID_WAIT().

Without this fake event, if the slave is already fully up-to-date with the
master, there may be no events sent at the given position for an indeterminate
time.

If the mysql.gtid_slave_pos table is not available, we cannot load nor update
the current GTID position persistently. This can happen eg. after an upgrade,
before mysql_upgrade_db is run, or if the table is InnoDB and the server is
restarted without the InnoDB storage engine enabled.

Before, replication always failed to start if the table was unavailable. With
this patch, we try to continue with old-style replication, after suitable
complaints in the error log. In strict mode, or if slave is configured to use
GTID, slave still refuses to start.

Now we give an error on attempts to set @@SESSION.gtid_domain_id or
@@SESSION.gtid_seq_no when a transaction is active.

There was some old code that cleared the position in CHANGE MASTER,
it was forgotten to be removed.

In addition, add code that saves/restores the old-style position
when we nuke the old relay logs as part of GTID slave start.
Normally we will not use these, but it could be useful in case
the GTID connect fails and user wants to go back to the old-style
coordinates.

mysql-test/r/servers.result:
  Added test case for MDEV-4594.
mysql-test/t/servers.test:
  Added test case for MDEV-4594.
sql/mysqld.cc:
  Move servers_init() call to init_server_components(), so it is called
  for embedded as well.
  
  Call servers_free() even if NO_EMBEDDED_ACCESS_CHECKS defined (because
  we call servers_init() anyway).

mysql-test/include/wait_show_condition.inc:
  Print failing statement if timeout
mysql-test/r/myisam-metadata.result:
  Updated DBUG_SYNC
mysql-test/t/myisam-metadata.test:
  Updated DBUG_SYNC.
  Removed wait_show_condtion, as this is not needed when we use DBUG_SYNC
  This should fix timing issues with the test
mysys/thr_mutex.c:
  Added comments
sql/sql_acl.cc:
  atoi -> atoll()  (Safety)
storage/myisam/ha_myisam.cc:
  Send signal before mi_repair_by_sort.

Test case fixes.

Fix problems related to reconnect. When we need to reconnect (ie. explict
stop/start of just the IO thread by user, or automatic reconnect due to
loosing network connection with the master), it is a bit complex to correctly
resume at the right point without causing duplicate or missing events in the
relay log. The previous code had multiple problems in this regard.

With this patch, the problem is solved as follows. The IO thread keeps track
(in memory) of which GTID was last queued to the relay log. If it needs to
reconnect, it resumes at that GTID position. It also counts number of events
received within the last, possibly partial, event group, and skips the same
number of events after a reconnect, so that events already enqueued before the
reconnect are not duplicated.

(There is no need to keep any persistent state; whenever we restart slave
threads after both of them being stopped (such as after server restart), we
erase the relay logs and start over from the last GTID applied by SQL thread.
But while the SQL thread is running, this patch is needed to get correct relay
log).

Test fixes.

sql/sp_head.cc:
  Trigger MYSQL_AUDIT_GENERAL_STATUS event for each statement in stored
  procedures. Not strictly needed for query_response_time plugin, but
  makes it behave more like Percona patch.

There were several cases where the slave GTID position was not loaded
correctly before being used. This caused various failures such as
corrupting the position at slave start and empty values of
@@gtid_slave_pos and @@gtid_current_pos.

Fixed by adding more checks for loaded position, and by always loading
the position at server startup.