Fix hiredis readiness checks for high file descriptors

[petyaslavova]

This fixes hiredis connection readiness checks for applications that can have socket file descriptors above FD_SETSIZE. The previous implementation used select.select(), which can raise ValueError: filedescriptor out of range in select() on high-numbered descriptors.

The readiness probe now uses selectors.DefaultSelector() instead. This lets Python choose the best platform selector, such as epoll, kqueue, or poll, while preserving the important behavior from #4063: can_read() remains non-destructive and does not read from the socket or consume hiredis parser state.

Tests were added to verify that the helper uses the default selector and can handle a real high-numbered file descriptor.

Fixes: #4113

---

Note

Low Risk
Narrow change to hiredis sync polling only, with new tests; behavior is intended to match prior non-destructive readiness checks on supported platforms.

Overview
Fixes hiredis sync connection readiness checks when Redis sockets use file descriptors above FD_SETSIZE, which could raise ValueError: filedescriptor out of range in select().

_socket_can_read in redis/_parsers/hiredis.py no longer uses select.select(); it uses selectors.DefaultSelector() (epoll/kqueue/poll where available) for the same non-destructive probe. SSL pending() short-circuit is unchanged, so can_read() still does not read from the socket or consume hiredis parser state.

Tests assert the helper registers for EVENT_READ via the default selector and that a high-numbered fd (via fcntl dup) can be polled without error when the platform default is not SelectSelector.

^{Reviewed by Cursor Bugbot for commit 778d244. Bugbot is set up for automated code reviews on this repo. Configure here.}

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}