Align s2n_connection_get_key_exchange_group() Behavior with Legacy APIs

[johubertj]

Problem:

s2n_connection_get_key_exchange_group() returns S2N_FAILURE when no named group is negotiated (e.g., in TLS 1.2 RSA key exchange), rather than returning a string like "NONE". This differs from the behavior of the functions it replaces s2n_connection_get_curve() and s2n_connection_get_kem_group_name(), both of which return "NONE" in that scenario.

Currently, this inconsistency can lead to confusion or breakage in downstream logs/metrics that expect a defined string value like "NONE". Furthermore, there’s interest in exploring whether a more explicit string like "RSA" could make logs/metrics more meaningful when RSA key exchange is used without a named group.

Solution:

Update s2n_connection_get_key_exchange_group() to return a defined string in the case where no named group is negotiated. Options include:

"NONE" (for backward compatibility, consistent with existing behavior in get_curve / get_kem_group_name, this is preferred for now)

"RSA" (to more explicitly identify the key exchange mechanism). This change would require coordination with logging/metrics consumers

Requirements / Acceptance Criteria:

When no named group is negotiated, s2n_connection_get_key_exchange_group() must return a consistent and documented string.

[WesleyRosenblum]

It was an explicit decision to not return NONE, see #5209 (comment). Returning NONE in this case introduces ambiguity, breaks type consistency, and makes the API harder to consume safely. The API is documented properly to indicate what will happen if an EC curve or KEM was not negotiated, so consumers are free to log any message they find appropriate (including NONE) for the error case.

Returning RSA from a function that specifically asks for elliptic curve or KEM group name doesn't seem appropriate either, since group_name is not an RSA concept.