Don't run fast_default regression test in parallel with other tests.

Since it sets up an event trigger that would fire on DDL done by any
concurrent test script, the original scheduling is just an invitation
to irreproducible test failures.  (The fact that we found a bug through
exactly such irreproducible test failures doesn't really change the
calculus here: this script is a hazard to anything that runs in parallel
with it today or might be added to that parallel group in future.  No,
I don't believe that the trigger is protecting itself sufficiently to
avoid all possible trouble.)

Discussion: https://postgr.es/m/5767.1523995174@sss.pgh.pa.us

src/test/regress/parallel_schedule

@@ -116,10 +116,12 @@ test: plancache limit plpgsql copy2 temp domain rangefuncs prepare without_oid c
 # ----------
 # Another group of parallel tests
 # ----------
-test: identity partition_join partition_prune reloptions hash_part indexing partition_aggregate fast_default
+test: identity partition_join partition_prune reloptions hash_part indexing partition_aggregate
 
 # event triggers cannot run concurrently with any test that runs DDL
 test: event_trigger
+# this test also uses event triggers, so likewise run it by itself
+test: fast_default
 
 # run stats by itself because its delay may be insufficient under heavy load
 test: stats

src/test/regress/serial_schedule

@@ -188,6 +188,6 @@ test: reloptions
 test: hash_part
 test: indexing
 test: partition_aggregate
-test: fast_default
 test: event_trigger
+test: fast_default
 test: stats