Wait a little after setting GUC, to make test more robust.

The 'fts_recovery_in_progress' fails sometimes with a diff like this:

    --- /tmp/build/e18b2f02/gpdb_src/src/test/regress/expected/fts_recovery_in_progress.out	2018-10-12 01:35:16.895897976 +0000
    +++ /tmp/build/e18b2f02/gpdb_src/src/test/regress/results/fts_recovery_in_progress.out	2018-10-12 01:35:16.899897976 +0000
    @@ -37,7 +48,7 @@
     show gp_fts_probe_retries;
      gp_fts_probe_retries
     ----------------------
    - 2
    + 5
     (1 row)

The test sets the 'gp_fts_probe_retries' GUC with gpconfig, changing it
from 5 to 2, and sends SIGHUP, and then issues the above SHOW statement to
verify that the change took effect. But on a busy system, the SIGHUP and
the config change might not reach the backend quickly enough. Add a 5
second delay, to give it more time. On a very busy system, even that might
not of course be enough, but let's see how far we get with this, before we
start inventing a more complicated waiting mechanism.

src/test/regress/expected/fts_recovery_in_progress.out

@@ -33,6 +33,13 @@ NOTICE:  Success:  (seg0 127.0.0.1:25432 pid=26540)
 \!gpconfig -c gp_gang_creation_retry_timer -v 250 --skipvalidation --masteronly
 \!gpstop -u
 -- end_ignore
+-- Wait a few seconds, to ensure the config changes take effect.
+select pg_sleep(5);
+ pg_sleep 
+----------
+ 
+(1 row)
+
 show gp_fts_probe_retries;
  gp_fts_probe_retries 
 ----------------------

src/test/regress/sql/fts_recovery_in_progress.sql

@@ -22,6 +22,8 @@ from gp_segment_configuration where content = 0 and role = 'p';
 \!gpconfig -c gp_gang_creation_retry_timer -v 250 --skipvalidation --masteronly
 \!gpstop -u
 -- end_ignore
+-- Wait a few seconds, to ensure the config changes take effect.
+select pg_sleep(5);
 show gp_fts_probe_retries;
 select gp_request_fts_probe_scan();
 select gp_wait_until_triggered_fault('fts_conn_startup_packet', 3, dbid)