SAVEPOINT IN ERROR HANDLER

Problem:
=======

When issuing a ROLLBACK TO SAVEPOINT within an error
handler, the slave asserts as follows:

mysqlcom-pro-5.6.24/sql/rpl_record.cc:246:
int unpack_row(const Relay_log_info, TABLE, uint,
const uchar, const MY_BITMAP, const uchar, ulong, const
uchar): Assertion `table_found' failed.

Analysis:
========

The above assert is caused in two cases.

CASE 1:
SAVEPOINT and ROLLBACK TO SAVEPOINT are inside a trigger and
followed by other DML statements.

SAVEPOINT, ROLLBACK TO SAVEPOINT statements are logged into
binary log as Query_log_events.
Query_log_event::do_apply_event() wipes out table map.
Events that follow the above Query_log_event will not find
table map event and it results in the above assertion.

CASE 2:

SAVEPOINT and ROLLBACK TO SAVEPOINT are inside a trigger and
and they does not follow with any DML statement.

In the above scenario On master during execution of
savepoint inside the trigger
"mysql_bin_log.write_event(&qinfo)" is called, which intern
invokes thd->binlog_flush_pending_rows_event() call with
"end_stmt" = false. This causes the peding event to be flushed
to the IO_CACHE without a STMT_END_F flag. Since it does't
follow with any DML stements no proper clean up is done. i.e
table maps are not cleared this causes the next query that
follows to be logged as part of query1 without its own table
map event resulting in same assert as mentioned in the bug.

Fix:
====

When a SAVEPOINT is executed inside a stored
function/trigger we force the pending event to be flushed
with a STMT_END_F flag and clear the table maps as well to
ensure that following DMLs will have a clean state to start
with. In the same way when we are rolling back to a
SAVEPOINT we should not only set the position back to
SAVEPOINT but also we must ensure that the same clean state
is preserved. In order to do that we clean the table maps
during rolling back to savepoint.