feat(proto): expose max_transmit_segments and max_transmit_datagrams in TransportConfig

[poka-IT]

Description

Replace the hardcoded constants MAX_TRANSMIT_SEGMENTS = 10 and MAX_TRANSMIT_DATAGRAMS = 20 in noq::Connection::drive_transmit with two configurable fields on TransportConfig. Defaults are unchanged (10 / 20), so default behavior is preserved.

New API:

let mut t = TransportConfig::default();
t.max_transmit_segments(NonZeroUsize::new(40).unwrap());
t.max_transmit_datagrams(NonZeroUsize::new(80).unwrap());

This is an alternative to #636 (which simply bumps the constants to 40 / 80 globally). After feedback from @flub there, exposing the values as a runtime knob seems more defensible:

• No default-behavior change: multi-connection workloads keep their per-connection memory footprint.
• Single-connection bulk-transfer workloads opt in: applications such as ours (peer-to-peer VPN tunnel over QUIC) can call transport.max_transmit_segments(NonZeroUsize::new(40).unwrap()) and get the throughput / CPU-efficiency gains demonstrated in the perf(connection): raise MAX_TRANSMIT_SEGMENTS to 40 and MAX_TRANSMIT_DATAGRAMS to 80 #636 benches.
• Pattern-consistent: same shape as enable_segmentation_offload, congestion_controller_factory, etc.

Why a setter rather than a higher default

MAX_TRANSMIT_SEGMENTS = 10 is exactly equal to MIN_BURST_SIZE in noq-proto/src/connection/pacing.rs:162, the historical 10 was likely chosen to match the pacer's minimum burst. The pacer itself, however, already allows up to MAX_BURST_SIZE = 256 per burst, so even a setter value of 256 stays within the existing pacer envelope. CC and pacing remain authoritative; the constants are just an outer cap.

Trade-offs now self-documenting

• Per-connection memory: max_transmit_segments * current_mtu bytes pre-allocated in TransmitBuf per Connection (rustdoc on the setter spells this out).
• Per-iteration CPU budget vs scheduler fairness (see comment in drive_transmit referencing Congestion window grows without bound when CPU-bound quinn-rs/quinn#1126).

Breaking Changes

n/a, defaults preserved (10 / 20).

Notes & open questions

• Tests added in noq-proto/src/tests/mod.rs:
  • default_max_transmit_settings: defaults remain 10 / 20.
  • max_transmit_segments_setter_caps_batch_size: setter at 4 caps the observed GSO batch size.
• All existing noq-proto and noq lib tests still pass locally.
• If you'd prefer to land perf(connection): raise MAX_TRANSMIT_SEGMENTS to 40 and MAX_TRANSMIT_DATAGRAMS to 80 #636 (pure constant bump) instead of this, I'm happy to close this PR and continue there. They are not mutually exclusive: perf(connection): raise MAX_TRANSMIT_SEGMENTS to 40 and MAX_TRANSMIT_DATAGRAMS to 80 #636 could land on top of this by changing the Default values.

Bench data motivating both PRs (paired same-session, 3x CCX23 Hetzner, real network: intra-DC and inter-region EU) is in the discussion thread of #636.

Change checklist

• Self-review.
• Tests (defaults preserved + setter behavior).
• No breaking changes.

[dignifiedquire]

I like this direction, as it reflects reality better, that these values need to be different depending on actual usage.