Problem 1:
The patch for BUG#17813449 introduced a new point where the SQL
thread sets GTID_NEXT. Before, the SQL thread only set GTID_NEXT
in Gtid_log_event::do_apply_event. Now, it additionally sets
GTID_NEXT in rpl_pre_statement_checks, when processing a relay log
from an old master that does not generate any Gtid events at all.
When setting GTID_NEXT for a slave thread, in 5.7 we also have to
copy the GTID to Slave_worker::currently_executing_gtid, so that
PERFORMANCE_SCHEMA.REPLICATION_EXECUTE_STATUS_BY_WORKER can read
it. This copying was missing in the first patch for the bug
because the patch was based on 5.6.
Fix 1:
Factor out the code for copying the GTID to
THD::set_currently_executing_gtid_for_slave_thread and call it from
both places.
Problem 2:
PERFORMANCE_SCHEMA.REPLICATION_EXECUTE_STATUS_BY_WORKER would
set the GTID wrong in corner cases:
- It assumes that the last executing transaction is ANONYMOUS
  just because gtid_mode=OFF. This is not necessarily true,
  we have to check the actual transaction type.
- If gtid_mode=off, it shows that the last executing transaction
  is 'ANONYMOUS' even if no transaction has been executed. It
  should show '' in this case.
Fix 2:
- Change type of currently_executing_transaction from Gtid to
  Gtid_specification, so that it can contain an anonymous
  transaction.
- Correct the logic in
  table_replication_execute_status_by_worker::make_row