Mysql server iterates backwards through binary logs, looking for
the last binary log that contains a Previous_gtids_log_event for
gathering the set of gtid_executed, and iterates forwards through
binary logs, looking for the first binary log that contains both
Previous_gtids_log_event and gtid_log_event for gathering the set
of gtid_purged on crash recovery. Mysql server also iterates
forwards through binary logs, looking for the first binary log
that contains both Previous_gtids_log_event and gtid_log_event
for gathering the set of gtid_purged when purging binary logs.
This may take very long time if the mysql server has many binary
logs and almost all of them are out of filesystem cache.

To fix the problem, introduce an option
'simplified-binlog-gtid-recovery', whose default value is false.
If the option is enabled, we do this: In the first scan (where
it iterates over binary logs from the newest to the oldest):
If the last binary log does not contain any GTID event, do not
read any more binary logs, and set GTID_EXECUTED = '' and
GTID_PURGED = ''. Otherwise, initialize GTID_EXECUTED as usual.
Then, in the second scan (where it iterates from the oldest to
the newest): If the first binary log does not contain any GTID
event, do not read any more binary logs, and set GTID_PURGED = ''.