Do not drop endpoint announcements or ACKNACKs on full channels

[johannesschrimpf]

Two internal channels of a DomainParticipant drop a message when they are
full:

• The DP event loop tells Discovery about each new local reader and writer
  over Discovery's 64-slot command channel with try_send
  (src/rtps/dp_event_loop.rs:1316-1331 at c076919). When the channel is
  full, the command is dropped with an error log, and nothing sends it
  again. Discovery writes an endpoint's SEDP sample only on that command
  (discovery.rs:759-764, 1830-1876), so the endpoint is never announced
  and no remote participant matches it, indefinitely; reliability cannot
  notice, because the sample never existed. The channel fills when an
  application creates many endpoints back to back (about two commands each;
  the AddTopic of create_datareader/writer uses it too) while Discovery
  is busy with other participants' SEDP samples or waiting for room in its
  own notification channel to the event loop.
• The message receiver forwards ACKNACKs and NACK_FRAGs to the local writers
  over a 100-slot channel with try_send (message_receiver.rs:862-892).
  When a burst fills it, the rest are discarded with an info log. The event
  loop drains the channel only on its readiness event; until then each of
  the four listeners can deliver up to 16 datagrams per poll, each carrying
  several submessages, and readiness-event ordering decides when the drain
  happens, so a crowd of readers answering the built-in writers' HEARTBEATs
  at once can exceed the 100 slots. A reader whose ACKNACK is discarded can
  wait until a subsequent HEARTBEAT prompts another one, so this loss delays
  reliable repair rather than preventing discovery.

One commit per channel, on master, independent of #447 and #449 (touches
different files; cherry-picks onto both without conflicts). Those two PRs
address the other mechanisms found in the same investigation.

1. Retry queue for discovery commands. A command that does not fit stays
   in a VecDeque on the event loop, later commands queue behind it (order
   kept), and the loop retries on every iteration, polling with its existing
   2 ms timeout while anything waits. After 5 s of waiting it warns once and
   logs when the queue drains again. A blocking send is not an option:
   Discovery sends its notifications to the event loop with a blocking send
   on a 32-slot channel that only the event loop drains, so two blocking
   sends would let the threads wait for each other. This change adds no
   blocking send; the three blocking StartKeyExchangeWithRemote* sends of
   the security feature are pre-existing and left for a follow-up. A
   command is dropped only when Discovery has exited, which on shutdown is
   the normal order and is logged at info.
2. Unbounded ACKNACK channel. Both ends of that channel are on the event
   loop thread, so back-pressure would deadlock at once; the channel becomes
   mio_extras::channel::channel() and forwarding uses send. What is
   queued between two drains is what the listeners read in that time, at
   most 16 datagrams per listener per poll; the per-poll limit bounds receive
   work, not the exact number of queued ACKNACKs, and further datagrams wait
   in the socket buffers.

Reproduction

Deterministic probes showed both drops at c076919 and on #449's branch: with
one free slot in the command channel, Discovery was told about only the first
of three new readers; with 101 ACKNACKs between two drains, one was
discarded. The two regression tests are trimmed versions of those probes.

The multi-process harness from #447 got a "burst" variant (two nodes create
40 publishers and 40 subscriptions each at start; a round fails unless all
160 endpoints match) and a 200-pair version. Before (#447 + #449) and after
(plus this PR): 0 unmatched endpoints in 4800 + 4000, crowd 30/30 both. The
harness did not reach the command-channel limit (an endpoint every 6-8 ms,
Discovery keeps up; the retry queue never engaged) and reached the ACKNACK
limit once (5 discards in 1 of 132 baseline rounds, every endpoint still
matched), so these runs show no harm rather than a fixed failure. The endpoint drop
was observed in runtime logs in #449's flood runs: bystanders creating 60
readers each logged "Failed to inform Discovery about the new endpoint" 3
times in 2 of 30 rounds. Timing differences between before and after were
within the spread of back-to-back control pairs.

Tests

In the tests module of src/rtps/dp_event_loop.rs, each failing with its
commit's non-test changes reverted:

• every_new_local_endpoint_is_announced_to_discovery: an event loop with a
  one-slot command channel has three new readers added on the test thread,
  so all three sends are attempted before anything drains; then the real
  event loop runs while a thread drains the channel as Discovery does. All
  three AddLocalReader commands must arrive in order. Fails without
  commit 1 (only the first arrives), passes with it.
• acknack_burst_reaches_writers: 200 ACKNACK datagrams from 200 readers
  before a drain; all 200 must come out of the channel towards the writers
  (it verifies delivery to the writer-dispatch queue, not the writers'
  processing). Fails without commit 2 (100 discarded), passes with it.

Not covered here

AddTopic is still try_send under the DiscoveryDB lock (only the
DCPSTopic sample is lost; matching does not use it); the security feature's
blocking sends; endpoint removal's try_send_timeout on 4-slot channels;
a queued add overtaken by a remove of the same endpoint (same outcome as a
late command before); and the stale-ACKNACK case after a reader resets its
writer proxy, which needs a decision on what ad9cfde re-serves.

Validation (macOS)

cargo test -- --test-threads=1 with and without --features security
(695 / 705 lib tests, the integration tests, 58 doctests; one later security
run had test::timestamp pick up a sample from a robot sharing domain 0 on
the network, and passed on a private domain); cargo clippy --all-targets
(both feature sets) clean; cargo +nightly fmt --check.

Developed with assistance from Claude Fable 5.1 and OpenAI Codex (gpt-6-astra).