feat: enhance address handling in EndpointState

[virajbhartiya]

Description

• Prefer newly provided app direct addresses immediately when updating an endpoint’s addresses.
• If Source is App or NamedApp and the current UDP send address isn’t part of the new set, clear validity for all existing direct paths and reset last_call_me_maybe to trigger immediate discovery instead of waiting the 6.5s trust window.
• Fixes slow reconnects when a server restarts with the same EndpointId but a new bind address.
  Closes Client sends to wrong address on server restart #3602
  Implementation details:
• In EndpointState::update_from_endpoint_addr:
  • Capture the current send address before acquiring the mutable guard.
  • Collect new_addrs into a Vec<SocketAddr> and update paths via the guard.
  • If the current address isn’t in the new set, clear path validities and reset last_call_me_maybe.

Also:

• Resolve a borrow conflict (E0502) by avoiding immutable access to udp_paths while a MutAccess guard is held.

Touched files:

• iroh/src/magicsock/endpoint_map/endpoint_state.rs

Breaking Changes

None.

Notes & open questions

• Scope-limited to Source::App and Source::NamedApp so discovery-initiated updates keep current behavior.
• We may later consider similar invalidation for other sources if empirical data shows benefits.

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.
  • List all breaking changes in the above "Breaking Changes" section.
  • Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are:
    • quic-rpc
    • iroh-gossip
    • iroh-blobs
    • dumbpipe
    • sendme

[flub]

Hi, I'm afraid we're not going to look into solving this on the main branch. This code changes drastically on the feat-multipath branch where we'll have a look at what the best approach is to solving this. Probably looking at QUIC PTO firing for this, which would apply in more situations.