master binlog read slow causes slave connect fail.

When slave connect to master, it send command to master query gtid for current binlog position (at lease when gtid replication is disabled).
Master then scans binlog for result.
When binlog is large, scan may take a long time.
During scanning, the slave report "Slave_IO_State: checking master version" which will confuse user.
The problem is: the slave (maybe) threat this long scanning time as network connect time, the default "slave-network-timeout" is insufficient for a large binlog scan. So the slave will timeout and try to reconnect. This will cause an event worse situation for master:new scanning will start while old scanning is on the way.

Then the slave will infinitely connect to master without success and the master will stressed by scanning binlog repeatly.