Implement connection refresh on circular moved

[alexr-bq]

Summary

Modifies behaviour of glide when receiving a MOVED request to the same address. Now this triggers a reconnect.

Features / Behaviour Changes

When Redis/Valkey servers are deployed behind DNS records, load balancers, or proxies, a MOVED error may be returned with a target endpoint that is the same endpoint from which the error originated.

Before this change, when Glide received a MOVED error pointing to the same endpoint, the retry would fail because:

1. The multiplexed connection writes the retry request to a local buffer (succeeds)
2. The server has already closed the connection after sending the MOVED response
3. The disconnection is only detected during the read phase
4. At that point, it's unsafe to retry because we can't determine if the server received the request
5. The error (FatalReceiveError) propagates back to the application

After this change, when a MOVED error points to the same endpoint (circular MOVED), the client:

1. Detects the circular condition by comparing the redirect address with the current connection address
2. Triggers a reconnection before retrying the command
3. The retry occurs on a fresh connection, allowing the DNS/proxy/load balancer to route to a different underlying server host

This fix is similar to StackExchange.Redis PR #3003 which addresses the same issue.

Implementation

Core fix in glide-core/redis-rs/redis/src/cluster_async/mod.rs:

In the RetryMethod::MovedRedirect handler (~line 1343), added detection for circular MOVED:

if let Some((redirect_addr, _slot)) = redirect_node {
    let is_circular = redirect_addr == address;
    if is_circular {
        log_debug_lazy!(
            "cluster",
            format!(
                "Detected circular MOVED redirect to same address: {}. \
                 Reconnecting before retry to avoid potential connection issues.",
                address
            )
        );
        // Reset routing and reconnect with retry
        request.info.reset_routing();
        return Next::Reconnect {
            request: Some(request),
            target: address,
        }
        .into();
    }
}

Key implementation details:

• Uses string comparison for address matching, consistent with how addresses are compared elsewhere in the codebase
• Returns Next::Reconnect with request: Some(request) which triggers reconnection AND queues the request for retry via pending_requests_tx
• Skips the normal slot refresh since the slot map is already correct (the endpoint is the same, just the underlying server changed)
• Only applies to MOVED errors, not ASK (ASK is a different scenario for temporary redirects during migration)

New tests in glide-core/redis-rs/redis/tests/test_cluster_async.rs:

Added two tests that verify the fix by tracking connection establishment (via PING count):

• test_async_cluster_circular_moved_triggers_reconnect - Tests GET command with circular MOVED
• test_async_cluster_circular_moved_set_triggers_reconnect - Tests SET command with circular MOVED

The tests verify that:

1. A reconnect occurs between the MOVED response and the successful retry (ping count increases)
2. The command ultimately succeeds

Limitations

• This fix only handles the async cluster client path. The sync cluster client may need a similar fix if it exhibits the same issue.
• The fix assumes that the MOVED address format matches the connection address format exactly (string comparison). This should always be true since both come from the same source format.

Testing

Unit tests:

• Two new MockEnv-based tests that verify reconnection occurs on circular MOVED
• Tests pass with the fix and fail without it (verified by temporarily commenting out the fix)
• Run with: GLIDE_VERSION=test cargo test --manifest-path glide-core/redis-rs/redis/Cargo.toml --test test_cluster_async -- test_async_cluster_circular_moved --nocapture

End-to-end test:

• Tested with a local custom proxy

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one issue.
• Commit message has a detailed description of what changed and why.
• Tests are added or updated.
• CHANGELOG.md and documentation files are updated.
• Linters have been run (make *-lint targets) and Prettier has been run (make prettier-fix).
• Destination branch is correct - main or release
• Create merge commit if merging release branch into main, squash otherwise.

[yipin-chen]

LGTM