Problem:

If "DROP TEMPORARY TABLE..." gets executed on server with GTID enabled and
read_only mode enabled, then 'DROP /!40005 TEMPORARY / TABLE IF EXISTS
sometablename' gets inserted in server binary log. This creates errant
transaction, that other slaves in cluster might not have and can break
replication if server with errant transaction gets promoted to master and
this transaction is already deleted from binary logs

Fix:

Do not write DROP TEMPORARY TABLE into binary log if nothing dropped.

The fix is implemented through following changes.
- Only count those temporary tables whose DROPs are actually going to
  be binlogged in mysql_rm_table for
  ER_GTID_UNSAFE_BINLOG_SPLITTABLE_STATEMENT_AND_GTID_GROUP
  diagnostic.
- In mysql_rm_table_no_locks, process tables temporary tables needing and
  not needing binlog separately.
- In mysql_alter_table, add a thd->decide_logging_format call in one of
  the temporary table opening paths in order to record the create-time
  binlog format for an ALTER TABLE-recreated temporary table correctly.