Add check to s2n_signature_scheme_valid_to_accept

[harrisonkaiser]

Resolved issues:

#1686

Description of changes:

This PR adds a check to the function s2n_signature_scheme_valid_to_accept which is used both in the negotiation and and validation phases of s2n's signature algorithm/scheme handling.

Specifically this check ensures the following for TLS1.3:

1. We don't use RSA as our signature scheme.
2. We don't use SHA 1 as our hash algorithm.
3. We have a signature curve if we are using ECDSA.

For TLS1.2 and before there are slightly different requirements:

1. We don't have a signature curve.
2. We don't use RSS_PSS_PSS as our signature scheme (Question: is this PSCK1?).

These checks mirror those in: tests/unit/s2n_security_policies_test.c. By moving them to runtime we gain a greater level of assurance that our checks aren't violated. For instance we can check against the actual_protocol_version.

These checks rely on the actual_protocol_version being set therefore it needed to be added in a few unit tests.

Call-outs/Questions:

Should these checks be in s2n_signature_scheme_valid_to_offer? It seems to me that either place is sufficient as both calls have to pass in order for the scheme to be used in a negotiation.

Quite a few tests don't set the actual_protocol_version_established flag, despite setting the actual_protocol_version. Is this merely a quirk of the tests or does the actual_protocol_version_established flag have some non-obvious meaning s.t. the state actual_protocol_version != 0 && actual_protocol_version_established == 0 has a meaning?

This is a partial implementation of the 3rd option listed in #1686:

Stop listing min/max protocol version on the sig schemes altogether and move the logic from the unit test in #1624 to here. That would check a signature alg is valid before we accept / choose it. The downside is less transparency and that we would need to do the checks at runtime, but they are very cheap checks.

By keeping the min/max protocol version on the sig schemes we keep the transparency; while safe guarding against the worst possible outcomes. The intent of this PR is to make it possible to remove the min/max protocol version in a future PR should we choose to.

It is also a implementation of the 1st option listed in #1686:

Add an additional check in CertVerify to make sure we're using a valid scheme. This theoretically shouldn't be necessary, but it would give a nice line of code to point at to prove we're definitely never signing with pkcs1 or sha1.

s2n_client_cert_verify_recv and s2n_tls13_cert_verify_recv both call s2n_get_and_validate_negotiated_signature_scheme which will only choose a candidate scheme for which s2n_signature_scheme_valid_to_accept is 0 (meaning it passes the checks).

Testing:

Ran unit tests locally + CI.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.