refactor: remove redundant inline timeout check from connect op

[sanity]

Context

PR #2174 initially added inline timeout checks to the connect operation's process_message method. However, Nacho pointed out in review that this is redundant.

Why This Is Redundant

The op_state_manager module already has a background task that handles transaction timeouts via ttl_set (see op_state_manager.rs lines 708-785). This handles timeouts for all operation types including Connect, so adding inline timeout checks in individual operation handlers is unnecessary duplication.

This PR

Removes the timeout additions that were added in the previous PR, per Nacho's feedback.

Stack

This PR stacks on #2174.

[AI-assisted - Claude]

[Copilot]

Pull request overview

This PR adds a 30-second timeout mechanism to detect and fail stalled connect operations when a joiner receives no acceptances or progress updates. The timeout prevents operations from waiting indefinitely when no peers respond.

Key changes:

• Added JOINER_PROGRESS_TIMEOUT constant (30 seconds) and has_timed_out() method to JoinerState
• Added timeout check in process_message that returns OpError::Timeout when timeout is exceeded
• Added Timeout variant to the OpError enum

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
crates/core/src/operations/mod.rs	Adds Timeout error variant to OpError enum for operation timeout failures
crates/core/src/operations/connect.rs	Implements timeout detection for joiner operations in WaitingForResponses state with 30-second progress timeout

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The timeout check only executes when a message is received. If a joiner receives no acceptances and no messages for 30 seconds (the exact scenario described in the PR description), process_message will never be called, so this timeout check will never execute and the operation will wait indefinitely.

Consider implementing the timeout via one of these approaches:

1. A periodic background task that checks for timed-out operations
2. A tokio timer/timeout wrapper around the operation
3. A timeout future that races with message processing

The current implementation only protects against stalls between messages, not the absence of messages entirely.

[iduartgomez]

Agreed this is not the place for this... we have a background task checking for transactions which may have timed out so this is kind of redundant actually. If we are not cleaning up, that's the place where we should be looking at.

[sanity]

Understood - I'll remove the inline timeout check. The existing op_state_manager background task already handles transaction timeouts via ttl_set (lines 708-785 in op_state_manager.rs), which covers Connect operations along with all other transaction types.

Removing the redundant code now.

[AI-assisted - Claude]

[Copilot]

The new timeout functionality lacks test coverage. Consider adding a unit test that verifies:

1. has_timed_out() returns false when last_progress is recent
2. has_timed_out() returns true when last_progress exceeds JOINER_PROGRESS_TIMEOUT
3. last_progress is updated correctly when progress occurs (acceptance or observed address update)

Example test structure:

#[test]
fn joiner_state_timeout_detection() {
    let old_instant = Instant::now() - JOINER_PROGRESS_TIMEOUT - Duration::from_secs(1);
    let state = JoinerState {
        target_connections: 1,
        observed_address: None,
        accepted: HashSet::new(),
        last_progress: old_instant,
    };
    assert!(state.has_timed_out(Instant::now()));
    
    let recent_state = JoinerState {
        target_connections: 1,
        observed_address: None,
        accepted: HashSet::new(),
        last_progress: Instant::now(),
    };
    assert!(!recent_state.has_timed_out(Instant::now()));
}