For temporary tables that are created with an engine that does
not provide the HTON_CAN_RECREATE, the truncate operation is
performed resorting to the optimized handler::ha_delete_all_rows
method. However, this means that the truncate will share
execution path, from mysql_delete, with truncate on regular
tables and other delete operations. As a consequence the truncate
operation, for the temporary table is logged, even if in row mode
because there is no distinction between this and the other delete
operations at binlogging time.

We fix this by checking if: (i) the binlog format, when the
truncate operation was issued, is ROW; (ii) if the operation is a
truncate; and (iii) if the table is a temporary table; before
writing to the binary log. If all three conditions are met, we
skip writing to the binlog. A side effect of this fix is that we
limit the scope of setting and resetting the
current_stmt_binlog_row_based. Now we just set and reset it
inside mysql_delete in the boundaries of the
handler::ha_write_row loop. This way we have access to
thd->current_stmt_binlog_row_based real value inside
mysql_delete.

mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  Updated result for spurious truncate table.
mysql-test/suite/binlog/t/binlog_row_innodb_truncate.test:
  Test case.
sql/sql_delete.cc:
  Added check in mysql_delete before writing the TRUNCATE statement
  to the binary log. Additionally, removed the set/reset of
  current_stmt_binlog_row_based so that it happens just in the 
  boundaries of the handler::ha_write_row loop inside mysql_delete.