INCONSISTENCY

Problem:
=======
If generating a GTID for a transaction fails, the
transaction is not written to the binary log but still gets
committed, which potentially leads to master/slave data
inconsistency.

Analysis:
========
Running out of GTID numbers is a very rare scenario, but if
that happens that will be a fatal error and we advise users
to 'Restart the server with a new server_uuid'.

GTID's are generated at the time of flushing binlog cache
to actual binary log. In the existing code if generation
of GTID fails, client will get an appropriate error message
and the action specified as per the binlog_error_action
will be taking place as this is a flush stage error. i.e
if the user chose binlog_error_action to be 'IGNORE_ERROR',
then binlog will be disabled and transactions will continue
to get committed on master and this will lead to an
inconsistent slave. If the user chose binlog_error_action
to be 'ABORT_SERVER' then server will abort without
commiting the transaction on master so it will be consistent
with slave. This behavior is the most appropriate one. At
present while displaying the error message in error log, it
is displayed as 'sync' stage error but it should be a
'flush' stage error.

Fix:
===
During flush stage if generation of GTID fails then we set
thd->commit_error= THD::CE_FLUSH_ERROR, so that the error
message is accurate.