On NetBSD, force dynamic symbol resolution at postmaster start.

The default of lazy symbol resolution means that when the postmaster
first reaches the select() call in ServerLoop, it'll need to resolve
the link to that libc entry point.  NetBSD's dynamic loader takes
an internal lock while doing that, and if a signal interrupts the
operation then there is a risk of self-deadlock should the signal
handler do anything that requires that lock, as several of the
postmaster signal handlers do.  The window for this is pretty narrow,
and timing considerations make it unlikely that a signal would arrive
right then anyway.  But it's semi-repeatable on slow single-CPU
machines, and in principle the race could happen with any hardware.

The least messy solution to this is to force binding of dynamic
symbols at postmaster start, using the "-z now" linker option.
While we're at it, also use "-z relro" so as to provide a small
security gain.

It's not entirely clear whether any other platforms share this
issue, but for now we'll assume it's NetBSD-specific.  (We might
later try to use "-z now" on more platforms for performance
reasons, but that would not likely be something to back-patch.)

Report and patch by me; the idea to fix it this way is from
Andres Freund.

Discussion: https://postgr.es/m/3384826.1661802235@sss.pgh.pa.us

src/template/netbsd

@@ -2,3 +2,12 @@
 
 # Extra CFLAGS for code that will go into a shared library
 CFLAGS_SL="-fPIC -DPIC"
+
+# We must resolve all dynamic linking in the core server at program start.
+# Otherwise the postmaster can self-deadlock due to signals interrupting
+# resolution of calls, since NetBSD's linker takes a lock while doing that and
+# some postmaster signal handlers do things that will also acquire that lock.
+# As long as we need "-z now", might as well specify "-z relro" too.
+# While there's not a hard reason to adopt these settings for our other
+# executables, there's also little reason not to, so just add them to LDFLAGS.
+LDFLAGS="$LDFLAGS -Wl,-z,now -Wl,-z,relro"