[p2p] Review Usage of Assertions for State Machine

[patrick-ogrady]

If messages are not delivered in expected order (need to look at guarantees of mpsc), it is possible we may see a flow of state transitions that looks invalid (and we'd panic rather than handling gracefully).

[0xAysh]

Hi @patrick-ogrady, Reviewed all unreachable!(), panic!(), and assert!() in p2p code (excluding #[cfg(test)]). From what I looked at, nothing needs to change.

discovery/actors/peer/actor.rs:333,380 - the unreachable!() on Payload::Greeting looked suspicious but is safe. The loop handles Greeting via an if let + continue before the match, so that arm is never reached. Out-of-order or duplicate greetings are already handled gracefully.

discovery/actors/dialer.rs:99, lookup/actors/dialer.rs:103 - unreachable!() on an unexpected Metadata variant. Reservations are constructed internally by the tracker and always carry Metadata::Dialer for this path, so this is not reachable via external input.

discovery/network.rs:211-223 - If a core actor (tracker, router, spawner, listener or dialer) exits, the network panics rather than running silently in a broken state.

discovery/types.rs:171 - inside arbitrary(), gated by #[cfg(feature = "arbitrary")]. The int_in_range(0..=3) makes the _ arm unreachable by construction.

All other panic! calls in listener.rs and tracker/actor.rs are inside #[cfg(test)].