"STOP/START SLAVE" USING GTID REPLICATION

Analysis: Slave updates 'GTID_RETRIEVED' set upon receiving
GTID_LOG_EVENT for a particular transaction which is first
event in the event group. Say, I/O thread is stopped *after*
adding GTID number to 'gtid_trieved' set and *before* it
actually retrieves all the events from that GTID event
group. Next time when this I/O thread is reconnected,
it sends union of GTID_RETRIEVED + GTID_EXECUTED
set to master. So Master thinks that slave is having all the
events from this GTID set(which includes partially
retrieved GTID) and it will not resend them again.
Hence slave is missing some events for ever.

Fix: It is not easy to find the end of a group of events.
So mysql server is unsure whether I/O thread retrieved the
last gtid transaction events completely or not
(before it is going down because of a crash/normal
shutdown/normal stop slave io_thread). It is possible that
I/O thread would have retrieved and written only partial
transaction events. So Server will request Master to send
the last gtid event once again. We do this by removing
the last I/O thread retrieved gtid event from
"Retrieved_gtid_set".
Possible cases:
1) I/O thread would have retrieved full
transaction already in the first time itself, but retrieving
them again will not cause problem because GTID number is same,
Hence SQL thread will not commit it again.
2) I/O thread would have retrieved full transaction already and
SQL thread would have already executed it. In that case,
We are not going remove last retrieved gtid from
"Retrieved_gtid_set" otherwise we will see gaps in "Retrieved set".