Revert "Still further tweaking of deadlock isolation tests."

This reverts commit d03130d3.
That was dependent on an isolationtester.c change that now proves
to be broken; we will need to find another solution.

src/test/isolation/expected/deadlock-hard.out

@@ -15,15 +15,12 @@ step s3a4: LOCK TABLE a4; <waiting ...>
 step s4a5: LOCK TABLE a5; <waiting ...>
 step s5a6: LOCK TABLE a6; <waiting ...>
 step s6a7: LOCK TABLE a7; <waiting ...>
-step s7a8: LOCK TABLE a8; SELECT pg_sleep(5); <waiting ...>
+step s7a8: LOCK TABLE a8; <waiting ...>
 step s8a1: LOCK TABLE a1; <waiting ...>
 step s8a1: <... completed>
-ERROR:  deadlock detected
-step s8c: COMMIT;
 step s7a8: <... completed>
-pg_sleep       
-
-               
+error in steps s8a1 s7a8: ERROR:  deadlock detected
+step s8c: COMMIT;
 step s7c: COMMIT;
 step s6a7: <... completed>
 step s6c: COMMIT;

src/test/isolation/specs/deadlock-hard.spec

 # This is a straightforward deadlock scenario.  Since it involves more than
 # two processes, the main lock detector will find the problem and rollback
 # the session that first discovers it.  Set deadlock_timeout in each session
-# so that it's predictable which session fails.  Also, when s8 fails and
-# rolls back, it unblocks s7, so that there is a race as to whether s7a8
-# or s8a1 will report first.  Add a delay in s7a8 to make that predictable.
+# so that it's predictable which session fails.
 
 setup
 {
@@ -61,7 +59,7 @@ step "s6c"	{ COMMIT; }
 session "s7"
 setup		{ BEGIN; SET deadlock_timeout = '100s'; }
 step "s7a7"	{ LOCK TABLE a7; }
-step "s7a8"	{ LOCK TABLE a8; SELECT pg_sleep(5); }
+step "s7a8"	{ LOCK TABLE a8; }
 step "s7c"	{ COMMIT; }
 
 session "s8"