This function is thread-safe.

This is the same as glib and should fix issues with old
compilers

Since the root certificates are already loaded it is not
necessary to load the certificates from the defualt paths

We're so close to returning the nice IANA ciphersuite name, except the
cipher name returned by GnuTLS uses hyphens instead of underscores.
Oops.

Noticed in
https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/262#note_1319023

It's failing because required dependencies have not been built. This
comment purports that it should suffice to uncomment the line once, run
the CI, and then trust that dependencies are updated going forward. But
this does not work reliably because there are multiple CI runners. So
just give up on it.

The Meson builds of libsoup under Visual Studio-like compilers give us
soup-3.0-0.dll and soup-2.4-1.dll for libsoup-3.x and libsoup-2.x
respectively, so make sure we look for the right DLL names.

We should rely on OpenSSL to do this for us instead. Doing it here is
wrong because we wind up checking certificates that may not actually be
used in the final certificate chain constructed by OpenSSL. We don't
have any way to know which chain OpenSSL will build from the
certificates that we pass to it, so there is no way to safely perform
certificate validity checks at the glib-networking level.

Fixes #179

Corresponding change for GTlsDatabaseGnutls:
https://gitlab.gnome.org/GNOME/glib-networking/-/commit/a2cc9b8e08063745d9ba1091e030fbe43fc5a055

Corresponding change for GTlsCertificateGnutls:
https://gitlab.gnome.org/GNOME/glib-networking/-/commit/e1a8d06648328f3c5cb2de5ca016de8ac3ddc2b2

Documented by:
https://gitlab.gnome.org/GNOME/glib/-/commit/780af9cff3cc636525a973c3f0c0244f2422a39e

This is bad, because it means the operation will no longer complete
immediately if cancelled by the API user. But it's better than crashing,
which is what is happening now. The underlying handshake operation is
synchronous, and this is tough to change, so we currently use
g_task_set_return_on_cancel() to fake it: this lets the API user think
the operation has completed, even if it's still running on the handshake
thread. Problem is this is broken and cannot be fixed easily:
glib-networking is not actually prepared for the task to finish early
like this. For now, ignoring cancellation is the most practical
solution to avoid crashes.

Of course this is not a good long-term solution. I have added a bullet
point to #89 in order to ensure I don't forget that we need to fix
cancellation.

Fixes #97, fixes #176

Previously we decided not to do this because it cannot be done properly,
which would require us to check each certificate in the chain for the
Must-Staple extension. The problem is we don't know which certificates
actually get used in the final verification path constructed by OpenSSL,
and don't want to consider certificates that are not used because that
leads to mistakes like #179.

But we *can* check Must-Staple on just the server cert. So let's do
that. Then we can get some actual real security benefit, which is
otherwise not possible because we have to ignore missing OCSP responses
if Must-Staple is not used.

Now, this isn't good enough -- we really ought to check for Must-Staple
on intermediate certificates too -- but it seems to be the best that is
possible with OpenSSL nowadays.

Credit to Patrick Griffis for originally writing much of this code. I've
stolen a lot of this from his previous work that was not accepted at the
time.

Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/197>

We will have two tests:

 (a) Test that Must-Staple extension is respected if set by a CA
certificate. This is the existing test, just renamed. It can only pass
for GnuTLS.

 (b) New test: ensure the Must-Staple extension is respected if set by a
server certificate. This test can pass for OpenSSL.

Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/197>

OpenSSL's OCSP support is quite old now.

Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/197>

 * The binding call should fail first of all, as tls-unique binding type
   is not defined under TLSv1.3. The test unit is updated accordingly.
 * New GnuTLS backend is handling it properly but old returns success/empty
   data - handle empty data and return error.
 * OpenSSL returns success (or rather Finished packet, as it is asked for)
   hence catch this condition before the call and return error.

Sending a "ClientHello" message with an SNI extension containing
the IP address, is forbidden, according to RFC 4366:
https://datatracker.ietf.org/doc/html/rfc4366#section-3.1

Part-of: <https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/200>