UCP/FT: probe-gated lane recovery via aux uct_ep_check

[evgeny-leksikov]

What?

Gate recovery of failed point-to-point lanes on an auxiliary endpoint probe before reconnecting the rebuilt lane.

Add coverage for successful probe-gated recovery, endpoint teardown with an outstanding probe, and recovery retry exhaustion while unaffected lanes remain usable.

Why?

Repeatedly reconnecting an endpoint over an unavailable route creates unnecessary churn. Silently resetting the failed transport endpoint can also leave inconsistent outstanding-operation accounting.

Probing first allows UCP to reconnect only when the route is usable while preserving communication over unaffected lanes.

How?

When a point-to-point lane fails:

• discard the failed transport endpoint and rebuild the lane with a wireup proxy containing a fresh inner endpoint;
• select a same-device auxiliary transport that supports endpoint checking;
• create an auxiliary endpoint using the packed peer interface address;
• keep the rebuilt endpoint encapsulated while the probe is outstanding;
• connect the rebuilt endpoint and replace the proxy only after probe success;
• retry recovery after probe failure up to the configured limit;
• cancel and release outstanding probe state during endpoint teardown via common discard flow.

[gleon99]

@jeynmann please review

[evgeny-leksikov]

Fixed

[evgeny-leksikov]

Yes, sequential multi-lane failures are supported. The recovery state and retry budget are per EP intentionally: a new lane failure restarts the address-exchange round for the current failed-lane set. The actual probe state is per lane (probe[UCP_MAX_LANES]), so the second failure does not overwrite the first lane’s probe.

A lane that becomes ready meanwhile is cleared independently. Reply processing intersects provided_lane_map with the current failed-lane map, so addresses for an already-restored lane are ignored, while newly failed lanes are restored from the subsequent exchange. Resetting retries_left for a new failure event is also intentional.