The reported assert in the slave temporary failing transaction block happens
*every* time when the replicated transaction faces a temporary error and
the slave's recovery tables (aka info repositories) are of the transactional
type. Indeed, such replicated deadlocked or timed-out transaction is to
be rolled back and re-tried whenever @@global.slave_trans_retries > 0.

Before it is rolled back, the applier calls global_init_info where
thanks to BUG16533802 fixes, global_init_info starts a new (short-lived) transaction
when relay_log_info_repository_type='TABLE'.
And that leads to an assertion about improper transaction state
because the temproary failing one it still active.

Fixed with relocating a part of general cleanup of the slave applier
(cleanup_context) to be executed before global_init_info().
Running the former function prior the latter must be safe and actually
makes much more sense.