feat(s2n-quic-core): add MtuConfigError with full diagnostic context

[mrwatts88]

Release Summary:

The mtu::Manager::config() method now returns Result<Config, MtuConfigError> instead of Result<Config, MtuError>. This is a breaking change for code that handles errors from this method, as error handling code will need to be updated to handle the new MtuConfigError type. The new error type provides better diagnostic context including the remote address, connection-specific MTU config, and endpoint MTU config when validation fails.

Resolved issues:

resolves #2254

Description of changes:

Previously, when MTU configuration validation failed in mtu::Manager::config(), it returned a generic MtuError that only provided a static message about the valid MTU range constraints. This made it difficult to diagnose why a specific configuration failed, especially in production environments where you need to know which remote address triggered the error and what the actual configuration values were.

This PR introduces a new MtuConfigError type that captures full diagnostic context:

• remote_addr: The remote socket address that caused the validation failure (owned inet::SocketAddress to avoid lifetime complications with SocketAddress<'a>)
• conn_config: The connection-specific MTU configuration that was invalid
• endpoint_config: The endpoint's MTU configuration for comparison

Implementation strategy:

• Created a new MtuConfigError type rather than extending MtuError because these are fundamentally different error scenarios: MtuError is for build-time validation failures when constructing MTU config, while MtuConfigError is for runtime validation failures when applying config to a specific path
• The new error type allows propagating both the endpoint and connection MTU configs for comparison, which wasn't possible with the generic MtuError
• Used an owned inet::SocketAddress instead of the borrowed SocketAddress<'a> to avoid lifetime management complexity in error propagation. Since this is an error path (validation failure), the performance impact of cloning the socket address should be small.

The mtu::Manager::config() method signature changes from Result<Config, MtuError> to Result<Config, MtuConfigError>, which is a breaking change requiring callers to update their error handling.

Additional changes:

• Added PartialEq, Eq, PartialOrd, and Ord derives to MTU types (MaxMtu, InitialMtu, BaseMtu) to enable comparison in error context
• Added PartialEq and Eq derives to mtu::Config to support equality checks in diagnostics
• Updated the DatagramDropReason::InvalidMtuConfiguration event variant to include conn_mtu_config and remote_addr fields
• Updated tests to verify the new error fields contain the expected diagnostic information

This change improves debuggability by providing actionable context when MTU configuration errors occur.

Call-outs:

Testing:

• Unit tests updated: Modified existing tests in quic/s2n-quic-core/src/path/mtu/tests.rs to verify the new MtuConfigError fields contain the correct diagnostic information
  • Tests verify remote_addr, conn_config, and endpoint_config are populated correctly when validation fails
  • Tests cover both validation failure cases: invalid config (base > initial > max constraint violated) and connection max MTU exceeding endpoint max MTU
• Compilation verification: The breaking change to mtu::Manager::config() is caught at compile time - the single call site in quic/s2n-quic-transport/src/path/manager.rs was updated to use the new error type
• Event generation: Verified the DatagramDropReason::InvalidMtuConfiguration event now includes the additional diagnostic fields (conn_mtu_config and remote_addr)

All existing tests pass with the new error type, confirming the behavior is unchanged except for the improved diagnostic context.

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

[maddeleine]

Hi, thanks for the contribution. Can you tell us more about your MTU usecase that drove the need for this PR?

[mrwatts88]

Hi, thanks for the contribution. Can you tell us more about your MTU usecase that drove the need for this PR?

I didn't have a specific use case, I just found an open issue.

[boquan-fang]

Hi @mrwatts88, thanks for contributing!

Do you mind adding a test or show us how would the MtuConfigError be displayed? Thanks!