Shared request queue: fetch_next_request does not immediately see newly added/reclaimed requests

[vdusek]

Context

Discovered during review of PR #803 (discussion).

The test_request_reclaim_functionality[shared] integration test is flaky because fetch_next_request() does not immediately return requests that were just added or reclaimed when using the shared request queue access mode. In the single mode, requests are added directly to the local queue_head deque and are available right away, but the shared client cannot do that.

Problem

When using shared request queue mode, there is a propagation delay between:

1. Adding a request (or reclaiming one) via the API
2. That request becoming visible in fetch_next_request()

This means users of the shared request queue mode may call fetch_next_request() and get None even though a request was just added or reclaimed.

Expected behavior

fetch_next_request() should reliably return requests that have been added or reclaimed, even in shared mode, without requiring the caller to implement their own retry/polling logic.

Current workaround

Callers need to poll fetch_next_request() with retries and delays to handle the propagation delay.

[janbuchar]

Just noting, isn't the expected flow more like while not rq.is_finished(): next_request = rq.fetch()? In that case, the fix (which will probably be just "wait for some reasonable time of rq.is_empty() and rq.locked_request_count == 0") will probably fit better into the is_finished method.