Honor GUC settings specified in CREATE SUBSCRIPTION CONNECTION.

Prior to v15, GUC settings supplied in the CONNECTION clause of
CREATE SUBSCRIPTION were correctly passed through to
the publisher's walsender. For example:

        CREATE SUBSCRIPTION mysub
            CONNECTION 'options=''-c wal_sender_timeout=1000'''
            PUBLICATION ...

would cause wal_sender_timeout to take effect on the publisher's walsender.

However, commit f3d4019 changed the way logical replication
connections are established, forcing the publisher's relevant
GUC settings (datestyle, intervalstyle, extra_float_digits) to
override those provided in the CONNECTION string. As a result,
from v15 through v18, GUC settings in the CONNECTION string were
always ignored.

This regression prevented per-connection tuning of logical replication.
For example, using a shorter timeout for walsender connecting
to a nearby subscriber and a longer one for walsender connecting
to a remote subscriber.

This commit restores the intended behavior by ensuring that
GUC settings in the CONNECTION string are again passed through
and applied by the walsender, allowing per-connection configuration.

Backpatch to v15, where the regression was introduced.

Author: Fujii Masao <masao.fujii@gmail.com>
Reviewed-by: Chao Li <lic@highgo.com>
Discussion: https://postgr.es/m/CAHGQGwGYV+-abbKwdrM2UHUe-JYOFWmsrs6=QicyJO-j+-Widw@mail.gmail.com
Backpatch-through: 15

Author: MasaoFujii

src/backend/replication/libpqwalreceiver/libpqwalreceiver.c

@@ -180,17 +180,6 @@ libpqrcv_connect(const char *conninfo, bool replication, bool logical,
 			/* Tell the publisher to translate to our encoding */
 			keys[++i] = "client_encoding";
 			vals[i] = GetDatabaseEncodingName();
-
-			/*
-			 * Force assorted GUC parameters to settings that ensure that the
-			 * publisher will output data values in a form that is unambiguous
-			 * to the subscriber.  (We don't want to modify the subscriber's
-			 * GUC settings, since that might surprise user-defined code
-			 * running in the subscriber, such as triggers.)  This should
-			 * match what pg_dump does.
-			 */
-			keys[++i] = "options";
-			vals[i] = "-c datestyle=ISO -c intervalstyle=postgres -c extra_float_digits=3";
 		}
 		else
 		{
@@ -256,6 +245,38 @@ libpqrcv_connect(const char *conninfo, bool replication, bool logical,
 		PQclear(res);
 	}
 
+	/*
+	 * Force assorted GUC parameters to settings that ensure that the
+	 * publisher will output data values in a form that is unambiguous to the
+	 * subscriber.  (We don't want to modify the subscriber's GUC settings,
+	 * since that might surprise user-defined code running in the subscriber,
+	 * such as triggers.)  This should match what pg_dump does.
+	 */
+	if (replication && logical)
+	{
+		const char *params[] =
+		{"datestyle", "intervalstyle", "extra_float_digits"};
+		const char *values[] = {"ISO", "postgres", "3"};
+
+		for (int j = 0; j < lengthof(params); j++)
+		{
+			char		sql[100];
+			PGresult   *res;
+
+			sprintf(sql, "SET %s = %s", params[j], values[j]);
+			res = libpqsrv_exec(conn->streamConn, sql,
+								WAIT_EVENT_LIBPQWALRECEIVER_RECEIVE);
+			if (PQresultStatus(res) != PGRES_COMMAND_OK)
+			{
+				PQclear(res);
+				*err = psprintf(_("could not set %s: %s"),
+								params[j], pchomp(PQerrorMessage(conn->streamConn)));
+				goto bad_connection;
+			}
+			PQclear(res);
+		}
+	}
+
 	conn->logical = logical;
 
 	return conn;