RELAY LOGS
Problem: When a binary log is used as a relay log
(transfer binary logs to Slave machine to avoid
I/O thread reading delay), MTS is unable to operate
on this kind of relay log.

Analysis: Multi thread Slave (MTS) returns error 1755
(ER_MTS_CANNOT_PARALLEL) if it finds an event if it does
not expect that event to be part of a group.
Previous_gtid_log_event on relay log generally generated by
relay logs when the relay log is rotated (with server_id
of the event as slave's event id) and MTS assumes that they
will anyways be skipped in (shall_skip()) logic when it finds that
server_id of the event is Slave's server_id. But It can happen
that some users (to avoid I/O thread reading delay) can copy
binary logs from Master as Slave's relay log and try to start SQL
thread to read the data from that relay log. In this case,
Previous_gtid_log_event's server_id will be Master's id which
is not same as slave's ID. So it will be not be skipped in
shall_skip() logic. Later when MTS finds this previous_gtid_log_event,
it throws error 1755(ER_MTS_CANNOT_PARALLEL).

Fix:
Previous Gtid Log events should always be skipped
there is nothing to apply there, whether it is
relay log's (generated on Slave) or it is binary log's
(generated on Master, copied to slave as relay log).
Previous_gtid_log_event::do_shall_skip() function
is added to skip this event all the time by SQL thread.