BINARY LOG WITH GTID AFTER CRASH
      Problem:
       Master's dump thread is not detecting the case where Slave's
       gtid executed set is having more gtids than Master's gtid
       executed set with respective to Master's UUID.

      Analysis & Fix:
       In normal scenarios, it is not possible that Slave will
       contain more gtids than Master with respective to Master's UUID.
       But it could be possible case if Master's binary log is
       truncated(due to raid failure) or Master's binary log is
       deleted but GTID_PURGED was not set properly. That scenario
       needs to be validated, i.e., it should *always* be the case that
       Slave's gtid executed set (+retrieved set) is a subset of
       Master's gtid executed set with respective to Master's UUID.
       If it happens, Master's dump thread will be stopped and this
       situation will be informed to Slave during the handshake (thus.
       slave I/O thread also be stopped with an error
       (ER_MASTER_FATAL_ERROR_READING_BINLOG). Otherwise, it can lead
       to data inconsistency between Master and Slave.