Bug#13627066 RPL.RPL_DEADLOCK_INNODB FAILS ON PB2 SPRADICALLY

Sporadic and long time standing mismatch at the test run
 
  include/start_slave.inc
  SET @@global.event_scheduler=1;
  -Number of received heartbeat events: 0
  +Number of received heartbeat events: 1

was caused by a incorrect assumption the no hearbeat event should
be sent in the context of that test's snippet.
In fact, there is no guarantee that empty binlog status won't last
over the hearbeat period. Even though period of scheduled by the server scheduler
UPDATE queries is 1/5 th of the heartbeat period, the actual time in between of two
successive bin-logging actions can last as long as the HB period. That's what PB run
proves in practice.

Fixed with removing ineffecient piece of the test.

Bug#13627066 RPL.RPL_DEADLOCK_INNODB FAILS ON PB2 SPRADICALLY

A possible reason of SQL thread to fail to increment slave_transaction_retries
status is a failure to start the slave threads that went unnoticible thanks to unblocking
style of the slave start. 
combined with also small of innodb_lock_wait_timeout. That could allow a race of 
the SQL thread retrying after timeout and the mtr user thread counting through polling in a interval.

Attempted to fix with correcting the start slave.
A separate failure in this test that radomly happens on PB near

 source include/wait_for_slave_sql_error.inc;

is addressed with adding a debug print-outs via rpl_debug=1.
Extra info will be necessary to actually tackle this issue (to be repoted once the extra info will
be available in PB saved test logs).