Problem :
---------
After a transaction trx1 is asynchronously rolled back by a
"high priority" transaction trx2, any statements executed on
trx1 gets deadlock error ER_LOCK_DEADLOCK. This is currently
true also for rollback statement i.e. ROLLBACK also returns
ER_LOCK_DEADLOCK.

This causes issue with replication. After ER_LOCK_DEADLOCK is
returned while executing a statement, server attempts complete
rollback of the transaction with each storage engine. In above
scenario, Innodb returns ER_LOCK_DEADLOCK again when
innobase_rollback is called. The error on rollback causes
MYSQL_BIN_LOG::rollback to skip some clean up operation. As a
result, the statements for the rolled back transaction are also
logged in binary log and replayed in slave.

For a table with unique index, the slave receives two entries
with duplicate values(one of which is actually rolled back in master)
causing "duplicate key" error and replication stops.

Solution :
----------
1. innobase_rollback to return SUCCESS if transaction is rolled back

2. innobase_rollback to ensure that the transaction is completely
rolled back before returning.

3. other internal calls to innobase_rollback() that expects abort error,
to return DB_FORCED_ABORT explicitly.

Reviewed-by: Sunny Bains <sunny.bains@oracle.com>

RB: 12278