Require runtime activation for the null cipher

[daverodgman]

As per #6792 (comment)

@gilles-peskine-arm notes:
We've previously talked about removing support for the null cipher in TLS, i.e. removing support for cipher suites where the data is authenticated but not encrypted. Mbed TLS supports this (though not in the default build). Note that #7588, so we should perhaps keep it.

@mpg continues:
Regarding NULL ciphersuites in TLS 1.2, I think it's also interesting to note that they were removed from TLS 1.3... only to be re-introduced by RFC 9150, published in April 2022 (but not the 1st). I think that this RFC, plus the issue report you linked to, can be taken as indications that some people still care about, as the RFC calls it, Authentication and Integrity-Only Cipher Suites, so perhaps we shouldn't remove them.

OTOH, in TLS 1.2, they have a non-zero maintenance cost, as they are the only ones in the "stream cipher" category. And of course their availability creates a risk of misconfiguration. However, I think that risk can be mitigated by making them opt-in not just at compile time (which they are now) but also at compile-time (exclude them from the list of ciphersuites unless explicitly requested - that's not the case right now).

[gilles-peskine-arm]

We have users who care about the null cipher, so we are keeping it as a feature.

I agree with Manuel's suggestion that allowing the null cipher should be a very explicit decision, requiring both enabling it at compile time (as today) and at runtime (which is not the case).

So the goal of this issue is: add a function on the SSL (context | configuration | both) (TBD) to allow null cipher suites. Test that a null cipher suite is used only if both the client and the server have explicitly enabled null cipher suites.