Re: Serverside SNI support in libpq

Hello!

I discovered one more issue: reload failure for a single host on
Windows / EXEC_BACKEND builds discards the entire SSL configuration
and lets the server run without it. This prevents connections that
require SSL, but allows those that only prefer it, downgrading them to
plaintext for the entire server, not just that host.

The easiest way to hit this is the passphrase reload=false issue which
is also present for the global configuration: since with EXEC_BACKEND
every new backend is basically a reload, if a certificate requires a
passphrase and the reload field isn't set, it only works in the
postmaster. So everything seems fine at server start, but then
backends can't use SSL at all.

After discovering this I implemented 0001, which makes this failure
more relaxed on Windows: as long as at least one configuration works,
we keep the configuration, only disabling SSL for the failing entries.

And after thinking about this further, in the most likely case where
the failure happens because of the reload parameter missing or set to
false, that is most likely already the case at postmaster start. So
why don't we simply refuse to start up in this case? That's 0002. We
still need 0001, since EXEC_BACKEND backends see config edits
immediately, so even if the configuration file was good at the start,
and we didn't perform any reloads after, new backends can still see an
edited broken configuration.

And we could apply the same logic to the global setting too: if we
have a single SSL configuration with a certificate requiring a
passphrase with SSL_passphrase_cmd_reload set to false, that
configuration will never work for any backend, so we should simply
refuse to start the server. That's 0003.

All this together still isn't perfect, as it can still result in
backends without a working SSL configuration, but unless we want to
completely error out in that case, I think this is the best we can do
to improve the situation.

All 3 patches also add the relevant documentation changes.