The test is supposed to provoke a deadlock, to test a crash of the server in
some deadlock scenarios.

The problem is that in recent version of MySQL, no deadlock occurs. It is not
clear why a deadlock should be expected. One transaction does an insert+delete
on primary key value 1 in table t2. The other transaction does an insert on
primary key value 123. There seems no reason that these should conflict, so
there is no deadlock.

(Presumably an earlier version did get a deadlock due to maybe taking excessive
locks on the insert+delete of primary key value 1. The table has only one row,
so maybe a different locking was used ("Impossible WHERE noticed after reading
const tables"))

Fix is to have transaction 1 lock PK 1 and transaction 2 lock PK 123. Then have
transaction 2 access PK 1 (wait) and transaction 1 access PK 123 (deadlock).

It has been checked that this modified test case still crashes the server in
the same way prior to fix of the original bug (Bug#24989).


mysql-test/include/read_many_rows.inc:
  Provoke deadlock on same PK value in the two transactions to ensure that the
  deadlock does occur independently on whatever execution plan is chosen.
mysql-test/r/read_many_rows_innodb.result:
  Result file update.