Fix logical replication TAP test to read publisher log correctly.

Commit 5f13999aa1 added a TAP test for GUC settings passed via the
CONNECTION string in logical replication, but the buildfarm member
sungazer reported test failures.

The test incorrectly used the subscriber's log file position as the
starting offset when reading the publisher's log. As a result, the test
failed to find the expected log message in the publisher's log and
erroneously reported a failure.

This commit fixes the test to use the publisher's own log file position
when reading the publisher's log.

Also, to avoid similar confusion in the future, this commit splits the single
$log_location variable into $log_location_pub and $log_location_sub,
clearly distinguishing publisher and subscriber log positions.

Backpatched to v15, where commit 5f13999aa1 introduced the test.

Per buildfarm member sungazer.
This issue was reported and diagnosed by Alexander Lakhin.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Discussion: https://postgr.es/m/966ec3d8-1b6f-4f57-ae59-fc7d55bc9a5a@gmail.com
Backpatch-through: 15

src/test/subscription/t/001_rep_changes.pl

@@ -341,7 +341,8 @@ $node_subscriber->safe_psql('postgres', "DELETE FROM tab_full_pk");
 # Note that the current location of the log file is not grabbed immediately
 # after reloading the configuration, but after sending one SQL command to
 # the node so as we are sure that the reloading has taken effect.
-my $log_location = -s $node_subscriber->logfile;
+my $log_location_pub = -s $node_publisher->logfile;
+my $log_location_sub = -s $node_subscriber->logfile;
 
 $node_publisher->safe_psql('postgres',
 	"UPDATE tab_full_pk SET b = 'quux' WHERE a = 1");
@@ -349,7 +350,7 @@ $node_publisher->safe_psql('postgres', "DELETE FROM tab_full_pk WHERE a = 2");
 
 $node_publisher->wait_for_catchup('tap_sub');
 
-my $logfile = slurp_file($node_subscriber->logfile, $log_location);
+my $logfile = slurp_file($node_subscriber->logfile, $log_location_sub);
 ok( $logfile =~
 	  qr/logical replication did not find row to be updated in replication target relation "tab_full_pk"/,
 	'update target row is missing');
@@ -425,11 +426,12 @@ is( $result, qq(11.11|baz|1
 #
 # First, confirm that no such QUERY STATISTICS message appears before enabling
 # log_statement_stats.
-$logfile = slurp_file($node_publisher->logfile, $log_location);
+$logfile = slurp_file($node_publisher->logfile, $log_location_pub);
 unlike(
 	$logfile,
 	qr/QUERY STATISTICS/,
 	'log_statement_stats has not been enabled yet');
+$log_location_pub = -s $node_publisher->logfile;
 
 # check that change of connection string and/or publication list causes
 # restart of subscription workers. We check the state along with
@@ -456,7 +458,7 @@ $node_publisher->poll_query_until('postgres',
 # Check that the expected QUERY STATISTICS message appears,
 # which shows that log_statement_stats=on from the CONNECTION string
 # was correctly passed through to and honored by the walsender.
-$logfile = slurp_file($node_publisher->logfile, $log_location);
+$logfile = slurp_file($node_publisher->logfile, $log_location_pub);
 like(
 	$logfile,
 	qr/QUERY STATISTICS/,
@@ -518,13 +520,13 @@ $node_publisher->reload;
 # Note that the current location of the log file is not grabbed immediately
 # after reloading the configuration, but after sending one SQL command to
 # the node so that we are sure that the reloading has taken effect.
-$log_location = -s $node_publisher->logfile;
+$log_location_pub = -s $node_publisher->logfile;
 
 $node_publisher->safe_psql('postgres', "INSERT INTO tab_notrep VALUES (11)");
 
 $node_publisher->wait_for_catchup('tap_sub');
 
-$logfile = slurp_file($node_publisher->logfile, $log_location);
+$logfile = slurp_file($node_publisher->logfile, $log_location_pub);
 ok($logfile =~ qr/skipped replication of an empty transaction with XID/,
 	'empty transaction is skipped');