feat(diameter): add loss-safe pending-request failover transactions

[VerifiedOrganic]

Summary

opc-proto-diameter exposes header flags and SWm request/answer correlation,
but it has no reusable pending-request transaction that can retransmit an
in-flight request safely to an alternate peer after transport failure.

The current SWm transaction stores only Hop-by-Hop and End-to-End identifiers.
Application builders always construct a fresh ordinary request, and the crate
explicitly leaves failover state machines outside its present boundary. A
consumer must therefore hand-manage the T flag, alternate-connection
Hop-by-Hop identifiers, late answers, duplicate suppression, and restart
recovery around sensitive multi-round EAP requests.

Current source evidence

Verified on SDK 0.2.0 at
709f4315443ed879f28c5d8524a019f7f1173587:

• CommandFlags can decode the T bit, but its normal request constructor has no retransmission argument.
• Application builders use a crate-private app_request_flags() that always returns an ordinary proxiable request; the SWm DER builder calls it directly at lines 1619–1627.
• SwmDiameterTransaction retains only the two identifiers. correlate_answer explicitly says the live transport must consume its own pending entry.
• The conformance document lists failover state machines outside current scope.

Standards requirement

RFC 6733 §5.1
describes primary/secondary peer operation. Section
5.5.4 requires a
per-peer pending queue and, when transport failure occurs, forwarding pending
requests to an alternate agent with the T flag set when possible. Section
3 requires Hop-by-Hop
uniqueness on each connection, preserves End-to-End identity for duplicate
detection, and requires duplicate requests not to apply state twice.

Required change

• Add a reusable DiameterRequestTransaction/pending-request primitive that
  owns a canonical request plus its immutable Origin-Host and End-to-End
  identity, current attempt(s), connection identity, and completion state.
• The first attempt uses a Hop-by-Hop identifier unique on its connection. A
  failover attempt preserves the semantic request and End-to-End identifier,
  sets the T flag, and uses a Hop-by-Hop identifier unique on the alternate
  connection. Retain all attempt identifiers so a late answer from either path
  can be recognized safely.
• Correlate answers to one pending transaction and expose one terminal
  completion while that live transaction exists. A late or duplicate answer may
  update bounded evidence but must not invoke the in-memory application callback,
  advance EAP, or mutate session state a second time.
• Distinguish failure before write, uncertain/partial write, successful write,
  transport loss, fixed Destination-Host with no valid alternate, retry
  exhaustion, and indeterminate completion.
• Support a versioned, explicitly sensitive snapshot/restore form for pending
  requests that a consumer may place in encrypted storage. Include a stable
  completion token and generation so a consumer can durably claim/ack delivery
  with compare-and-set or make restored delivery idempotent. Without that
  external durable protocol, document restored completion delivery as
  at-least-once rather than claiming crash-proof exactly-once behavior. Do not
  add a plaintext persistence backend or include EAP, User-Name, Session-Id,
  realm, destination, or raw request bytes in Debug, errors, metrics, or
  traces.
• Make attempt limits, deadlines, peer selection, and whether an alternate is
  routable caller policy. The primitive owns wire correctness, correlation,
  live at-most-once completion, and stable restored-delivery identity.

Acceptance criteria

• Deterministic tests cover association loss before write, after a complete
  write but before answer, partial/unknown write disposition, alternate success,
  alternate failure, and exhaustion.
• Every alternate attempt has T=1, the exact original End-to-End identifier and
  Origin-Host, and a Hop-by-Hop identifier proven unique on the selected
  connection. The original semantic AVPs are unchanged except for routing AVPs
  that RFC 6733 permits an agent to update.
• Late original answers, late alternate answers, duplicated answers, reordered
  answers, and simultaneous answers cause the callback of one live transaction
  to run at most once.
• A multi-round SWm EAP transaction remains sticky and advances by one validated
  answer only; failover never manufactures an EAP packet or a new application
  request.
• Snapshot/restore retransmits still-pending records with T=1, rejects stale or
  malformed snapshots, preserves a stable completion token/generation across
  repeated restores, and never serializes sensitive values through a diagnostic
  representation. Tests demonstrate at-least-once restored delivery and the
  optional durable claim/ack integration needed for crash-safe deduplication.
• Fixed-destination and no-alternate cases return a typed inability-to-deliver
  outcome rather than silently dropping or rewriting the destination.
• All pending/attempt tables are bounded, cancellation-safe, and use
  deterministic clocks in tests.

Non-goals

• Peer discovery, realm routing, load balancing, watchdog timing, or deciding
  which alternate peer is valid.
• Persisting requests to unencrypted local storage.
• Making application side effects idempotent on behalf of a consumer.
• Retrying a request whose application semantics prohibit failover.

Related issues

#184, #192, and #290 improve SCTP multihoming and path behavior. Kernel SCTP
path failover does not replace RFC 6733 application-request failover to an
alternate Diameter peer.