Bug#21114464  CRASHES WITH CONCURRENT DDL+KILL+BIN LOGGING

The root cause of the problem is that CREATE ... SELECT has a commit
in the middle when binlog_format=row and gtid_mode=off. The original
purpose of introducing the commit was that it is logged as:
  Anonymous_gtid_log_event
  CREATE TABLE
  Anonymous_gtid_log_event
  BEGIN
  rows event
  COMMIT
This may be a mistake, since it is also logged as above without the
commit. The reason is that 'CREATE TABLE' event is logged into
binlog statement cache with an Anonymous_gtid_log_event and rows
event generated by 'SELECT' part with an Anonymous_gtid_log_event
is logged into binlog transaction cache.

To fix the problem, CREATE ... SELECT does not do the commit in the
middle when binlog_format=row any more. After the fix, we reset the
binlog statement cache when rolling back a single statement
'CREATE...SELECT' transaction, since the 'CREATE TABLE' event was put
in the binlog statement cache (not synchronized into the disk). The
rollback can be caused by killing the query from other connection or
an error happened on DML part of CREATE...SELECT. We also remove the
thd->pending_gtid_state_update flag, since it is not needed any more.