Enable TLS 1.3 for libressl and boringssl libcryptos

[goatgoose]

Problem:

Now that TLS 1.3 is supported in libressl and boringssl, TLS 1.3 should be enabled when building with these libcryptos in s2n-tls. s2n-tls determines if the libcrypto has support for TLS 1.3 here: https://github.com/aws/s2n-tls/blob/69cc503704a28fc7d2b75999b22cda623df06b84/tls/s2n_tls13.c#L29

However, libressl and boringssl aren't enabled due to checks here: https://github.com/aws/s2n-tls/blob/69cc503704a28fc7d2b75999b22cda623df06b84/crypto/s2n_rsa_pss.h#L37

and here: https://github.com/aws/s2n-tls/blob/69cc503704a28fc7d2b75999b22cda623df06b84/crypto/s2n_rsa_signing.h#L25

When s2n-tls is built with libressl, the openssl version number is set to the version of openssl when libressl first branched, and the libressl version number is ignored: https://github.com/aws/s2n-tls/blob/69cc503704a28fc7d2b75999b22cda623df06b84/crypto/s2n_openssl.h#L28

This should likely be removed in favor of using LIBRESSL_VERSION_NUMBER directly whenever checking support for a feature.

Additionally, any changes needed to allow s2n-tls to use the TLS 1.3 features of libressl and boringssl should also be made.

Solution:

Enable TLS 1.3 when building with libressl and boringssl, and make any changes needed to use TLS 1.3 features properly with these libcryptos.

• Does this change what S2N sends over the wire? If yes, explain.
  • No
• Does this change any public APIs? If yes, explain.
  • No
• Which versions of TLS will this impact?
  • 1.3

Requirements / Acceptance Criteria:

When s2n-tls is built with libressl and boringssl, TLS 1.3 unit tests aren't skipped and succeed, and TLS 1.3 V2 integration tests succeed when re-enabled for these libcryptos.

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?