Among two claimed artifacts the critical one is in that the Table map of 
a query following the failing with a duplicate key error CREATE-SELECT is skipped from
instantionating (and thus binlogging). That leads to sending a "chopped" group of the data
row-events without the table map head to the slave. 
The slave can not apply the only data row events.
It's not easy to force the slave to react with an error in such a case (the second complaint
on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event
handler is a common situation which  normally designates the event has to be filtered out
basing on the repliation do/ingore rules decision.

Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in
select_create::abort().
No error is reported if by chance the table map was not been binlogged.
Leaving this out to resolve with considering how to combine the do/ingore rules with the situation
when erronoulsy the Table_map is not written to binlog.


mysql-test/suite/rpl/r/rpl_row_create_table.result:
  results changed
mysql-test/suite/rpl/t/rpl_row_create_table.test:
  regression test for the bug
sql/sql_insert.cc:
  adding resetting of thd binlogging state that was missed for the particular case of failing CREATE..SELECT