Add Getter for negotiated SupportedGroup name

[alexw91]

Problem:

Neither s2n_connection_get_curve() or s2n_connection_get_kem_group_name() return the name of the SupportedGroup that was negotiated during a TLS connection. s2n_connection_get_curve() returns the correct result if a classical ECDH curve was negotiated, but returns only the ECDH-half if a Hybrid PQ key exchange was negotiated; and s2n_connection_get_kem_group_name() returns the full Hybrid SupportedGroup name if a hybrid PQ key exchange was neogitated, but returns "NONE" if a classical ECDH key exchange was negotiated.

Users can re-generate the SupportedGroup name by calling both of these API's and preferring the KemGroup name if it's value is not "NONE", and falling back to the Curve name otherwise, but this pattern is not ergonomic. We should have a new s2n_connection_get_group_name() API that returns the name of the SupportedGroup that was negotiated.

TLS Version	PostQuantum?	SupportedGroup Negotiated	s2n_connection_get_curve() Output	s2n_connection_get_kem_group_name() Output	New s2n API?
TLS 1.3	No	secp256r1	"secp256r1"	"None" (Is not ECDH curve name)	"secp256r1"
TLS 1.3	Yes	secp256r1_kyber-512-r3	"secp256r1" (Is not full hybrid name)	"secp256r1_kyber-512-r3"	"secp256r1_kyber-512-r3"

Solution:

Implement a new s2n API with this interface: int s2n_connection_get_group_name(struct s2n_connection *conn, char** group_name_out)

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
• Related Issues: None
• Will the Usage Guide or other documentation need to be updated? Yes, we will new new API documentation for this change
• Testing: Unit tests with regular and PQ Key exchanges that confirm the actual and expected names match
  • Will this change trigger SAW changes? No, formal verification is not necessary for a new getter API.
  • Should this change be fuzz tested? No, fuzz tests are not necessary for a new getter API.

Out of scope:

Is there anything the solution will intentionally NOT address? No