Speed up gp_replica_check, by not waiting for apply of first chckpoint.

Optimistically start the comparison, without waiting the standby to replay
the checkpoint that is issued at the beginning of gp_replica_check. If
there are any recent on-disk data changes, we will find that a data file
doesn't match. But that's OK, we will retry. But in the common case that
there are no recent changes, this greatly speeds up gp_replica_check.
In particular, if you run gp_replica_check on multiple databases, like
"make installcheck" does, the gp_replica_check() call on the first database
will perform a checkpoint, but the calls on subsequent databases will
likely go through without waiting for any more checkpoints.

contrib/gp_replica_check/gp_replica_check.c

@@ -538,18 +538,17 @@ gp_replica_check(PG_FUNCTION_ARGS)
 	DIR *mirrordir = AllocateDir(mirrordirpath);
 
 	/*
-	 * Checkpoint and wait until the standby has replayed it.
+	 * Checkpoint, so that all the changes are on disk.
 	 *
-	 * XXX: There is currently no guarantee or wait that the standby has
-	 * performed a restartpoint based on the checkpoint record, so this is
-	 * not very robust.
+	 * XXX: There is currently no guarantee that the standby has performed a
+	 * restartpoint based on the checkpoint record. If it hasn't, any recent
+	 * changes are not visible to us in the standby yet, and the file
+	 * comparison will find that the files don't match. That's OK, we will
+	 * issue a new checkpoint, wait, and retry a few times, so the standby
+	 * should converge to the same state as the master eventually, hopefully
+	 * before we give up.
 	 */
-	if (!sync_wait())
-	{
-		ereport(WARNING,
-				(errmsg("unable to obtain start synced LSN values between primary and mirror")));
-		PG_RETURN_BOOL(false);
-	}
+	RequestCheckpoint(CHECKPOINT_IMMEDIATE | CHECKPOINT_FORCE | CHECKPOINT_WAIT);
 
 	/* Store information from pg_class for each relfilenode */
 	HTAB *relfilenode_map = get_relfilenode_map();