Avoid holding the Sentinel mutex across I/O

[OskarEichler]

Move Sentinel network I/O outside the shared mutex, single-flight resolution across threads, allow same-thread fibers to progress with independent short-lived clients, and make reset and Sentinel-list updates concurrency-safe.

Verification: the same-thread fiber reproduction changes ThreadError to two successful resolutions; 20 concurrent threads perform one resolution; focused Ruby 4.0.6 checks, RuboCop, and gem build pass. The full Sentinel integration harness was unreliable locally on Ruby 4 / Redis 7, so upstream CI is requested. Source-only patch; no tests included.

[OskarEichler]

@byroot Thanks for reviewing this. Could you clarify why the PR was closed—was the concurrency model unsuitable, or is there another intended direction for Sentinel resolution?

The reproduced issue is that Sentinel network I/O occurs while holding the shared mutex: same-thread fibers can raise ThreadError, and one slow Sentinel request serializes otherwise independent callers. The patch moves resolution outside the shared lock, single-flights competing threads, gives same-thread fibers independent short-lived clients, and synchronizes reset/Sentinel-list updates. In focused verification, the fiber reproduction changed from ThreadError to two successful resolutions, and 20 concurrent threads performed one resolution.

The full Sentinel integration harness was unreliable locally, so if closure was due to verification or scope I’m happy to revise the approach and add focused upstream regression tests.