Add test tracking WAL receiver shutdown for primary_conninfo updates

The test introduced by this commit checks that a reload of
primary_conninfo leads to a WAL receiver restarted, by looking at the
request generated in the server logs.  This is something for what there
was no coverage.

This has come up for a different patch, while discussing a regression
where a WAL receiver should not be stopped while waiting for a new
position to stream, like at the end of a timeline.  In the case of the
other patch, we want to check that this log entry is not generated, but
if the error message is reworded the test would become silently broken.
The test of this commit ensures that we at least keep track the log
message format, for a supported scenario.

Extracted from a larger patch by the same author.

Author: Xuneng Zhou <xunengzhou@gmail.com>
Discussion: https://postgr.es/m/aQKlC1v2_MXGV6_9@paquier.xyz

src/test/recovery/t/040_standby_failover_slots_sync.pl

@@ -344,8 +344,20 @@ like(
 ##################################################
 
 $standby1->append_conf('postgresql.conf', "primary_conninfo = '$connstr_1'");
+
+# Capture the log position before reload to check for walreceiver
+# termination.
+$log_offset = -s $standby1->logfile;
+
 $standby1->reload;
 
+# Wait for the walreceiver to be stopped and restarted after a configuration
+# reload.  When primary_conninfo changes, the walreceiver should be
+# terminated and a new one spawned.
+$standby1->wait_for_log(
+	qr/FATAL: .* terminating walreceiver process due to administrator command/,
+	$log_offset);
+
 ($result, $stdout, $stderr) =
   $standby1->psql('postgres', "SELECT pg_sync_replication_slots();");
 like(