LibreSSL and OpenSSL separation in libpq to support 1.1.1 deprecation

Since the discussion on the minimum supported version of OpenSSL for v20 has
kicked off, I wanted to share what I believe is an important step on the path
to OpenSSL modernization; namely how to deal with LibreSSL.

Our LibreSSL support is currently based on the OpenSSL code and the OpenSSL
compatibility in LibreSSL, so much so that for quite some time we didn't even
document that it was supported even though it was buildfarm tested. Over time
we've accumulated more ifdefs for differences in API support. If we want to
modernize our OpenSSL support in libpq with v3+ API's once we've deprecated
1.1.1, the code will soon become unreadable and IMHO, a CVE hazard.

LibreSSL supports the 1.1.1 API, and they dont have the manpower to keep up
with the rapid pace of OpenSSL development so are likely to stay there for the
foreseeable future. The libraries have already started diverging quite a lot
and it will continue (LibreSSL have also developed their own API which if I
were them is what I'd focus on).

As I can see it we have two choices wrt LibreSSL if we want to move past 1.1.1;
either deprecate support or separate it out such that OpenSSL and LibreSSL can
move at their own pace. I don't like the idea of deprecating LibreSSL so I
favor the latter alternative.

The attached implements LibreSSL as a separate TLS library implementation (*)
in libpq with fe-secure-libressl.c and be-secure-libressl.c along with build
and test infrastructure. This is a PoC rather than a polished for-inclusion
patch as of now, since I wanted to get the discussion going. Some of the known
TODO items include:

- Autoconf support is a POC and not tested at all yet, only the
Meson side has been tested as of now
- include/common/openssl.h needs to either be renamed, copied
or at least have its comments extended
- test/ssl/t/SSL/Backend/OpenSSL.pm has been hackily extended
for now, the exact level of changes required here are not
clear, and a future move to pytest may influence how much we
want to invest here
- the discovery in meson.build is likely rubbish and could be
cleaned up by our Meson experts
- there are likely lots of comments still that mention OpenSSL
which could be expanded to say something about LibreSSL
- documentation of the build option is missing
- we can simplify a few uses of USE_OPENSSL || USE_LIBRESSL to
just USE_SSL

There are no new features introduced (and none removed) or API usage changes,
the only changes are to cut away the ifdefs and only keep the code we actually
need per file. This way the differences are quite easy to check by diffing
{fe|be}-secure-{openssl|libressl}.c.

While this duplicate a lot of code, it doesn't really add a maintenance burden
we don't already carry since we do support LibreSSL already, but it does alter
the burden for sure (not least when it comes to backpatching). That being
said, staying on a long-since deprecated API level (we are at 1.0.1 with
warnings silenced) also doesn't sound great.

One option is to not do this until we have a case where we want to use a v3+
API and only do it then as a prerequisite step; keeping the patch rebased in
the back-pocket till that day comes. Personally I have serverside SNI support
for LibreSSL on my radar for v20, which will need such a split in order to keep
the files readable as it will be implemented quite differently from its OpenSSL
counterpart.

All of the above is of course moot if we don't move the needle past 1.1.1 in
v20..

--
Daniel Gustafsson

(*) Yes. The irony of me proposing to add a new TLS library implementation to
postgres is *not* lost on me.