Introduce openssl backend for v1 and v3 API separation

[bukka]

The main purpose of this is to better handle the API difference and add an inital work to separate PHP and OpenSSL logic. This is really just the first step and further changes are coming after that.

The motivation for this is #14734 which would basically make the current code messy and introduce many ifdefs. The thing is that the v1 API will need to be maintained for some time as 1.1.1 is still used as default in RHEL 8 which has EOF in 2029. In addition there is LibreSSL that might become even more incompatible so even once we no longer need to support 1.1.1, we might still want to support LibreSSL and it's not clear if it's going to ever get providers.

[cmb69]

1.1.1 is still used as default in RHEL 8 which has EOF in 2029

shakes head

But okay, I guess we will have to deal with this, one way or another. Separating the backends makes sense to me, especially since openssl.c is already too big for my taste, but I'm afraid that this will cause big merge-troubles for years, and we might even miss to apply relevant fixes to all back-ends (cf. dns.c vs. dns_win32.c). That might especially be worrysome if we don't have a CI job running against OpenSSL 1.1.

[bukka]

Yeah we should at least have nightly job to run OpenSSL 1.1.1 and maybe LibreSSL might be good idea too. It might be actually used to also test older versions of other libraries or alternative implementations (e.g. MariaDB for mysqli).

In terms of merge troubles, I can't think about any other way but it's probably better than automerge to just a single back-end because it might give at least a hint that there might not be just one backend to change. Also there's not such a huge number of updates going to openssl.c in terms of bug fixes so might not be such a huge issue.

[bukka]

Just a heads, that if there are no objections I will merge this later this week.

As the next step I'm looking to cleaning up the 1.0.2 specific bits that are no longer supported and we kept them just for LibreSSL. But looking at it, this applies only to very old LibreSSL versions anyway (before 2.7 from what I read). I'm thinking about setting minimum to 3.0.2 but I don't have a good visibility into where it's actually used. I know it's used in OpenBSD which seems to have last stable supported versions 7.5 which uses 3.9.0 so maybe we can go higher than 3.0.2 with minimal version. @devnexen What do you think?

[devnexen]

OpenBSD uses it as its default TLS library. FreeBSD allows you to set the TLS of your choice, not sure how much users actually set to libressl, but that is a possibility. There is libressl for openbsd and libressl for "the rest" (using wrappers to map openbsd native calls) but they should be the same api and behavior-wise. Using 3.0.2 as minimum is very reasonable IMHO.

[bukka]

So I have been doing some testing with LibreSSL. It took me a bit to realise that version from git does not exactly work on Linux (seems OpenBSD specific) but the tarballs work so I have been checking the versions. And currently the oldest version that compiles from 3.x is 3.5.0 due to missing EVP_CTRL_AEAD_GET_TAG in previous versions. So the minimum supported is 3.5.0 and allowed some clean up as in #18032 .

Btw there are bunch of tests failures because it stripped some features and we don't do any checks for that. So it's more a support just to make it compile atm. It might improve in the future but it's not a priority.