catalog access with reset GUCs during parallel worker startup

Hi,

I noticed that during ParallelWorkerMain()->RestoreGUCState() we perform
catalog accesses with GUCs being set to wrong values, specifically values that
aren't what's in postgresql.conf, and that haven't been set in the leader.

The reason for this is that

1) RestoreGUCState() is called in a transaction, which signals to several GUC
hooks that they can do catalog access

2) RestoreGUCState() resets all non-skipped GUC values to their "boot_val"
first and then in another pass sets all GUCs that were non-default in the
leader.

This e.g. can lead to parallel worker startup using the wrong fsync or
wal_sync_method value when catalog accesses trigger WAL writes. Luckily
PGC_POSTMASTER GUCs are skipped, otherwise this'd be kinda bad. But it still
doesn't seem good.

Do we really need to reset GUCs to their boot value? Particularly for
PGC_SIGHUP variables I don't think we can do that if we want to do
RestoreGUCState() in a transaction. It'd obviously involve a bit more code,
but it seems entirely possible to just get rid of the reset phase?

Greetings,

Andres Freund