Fallback to using async_timeout on older python

asyncio.wait_for has some underlying problems that are only fixed in
cpython 3.12. See python/cpython#98518

asyncio.wait_for has some underlying problems that are only fixed in cpython 3.12.

Use async_timeout instead until the minimum supported version is 3.11+ and it can be replaced with asyncio.timeout

See python/cpython#98518

async_timeout does not suffer from the same race
problems as asyncio.wait_for

see python/cpython#98518
for more details

wasted some time because asyncio.wait_for() was suppressing cancellations. [0][1][2]
deja vu... [3]

Looks like this is finally getting fixed in cpython 3.12 [4]
So far away...
In attempt to avoid encountering this again, let's try using
asyncio.timeout in 3.11, which is how upstream reimplemented wait_for in 3.12 [4], and
aiorpcx.timeout_after in 3.8-3.10.

[0] python/cpython#86296
[1] https://bugs.python.org/issue42130
[2] https://bugs.python.org/issue45098
[3] kyuupichan/aiorpcX#44
[4] python/cpython#98518

wasted some time because asyncio.wait_for() was suppressing cancellations. [0][1][2]
deja vu... [3]

Looks like this is finally getting fixed in cpython 3.12 [4]
So far away...
In attempt to avoid encountering this again, let's try using
asyncio.timeout in 3.11, which is how upstream reimplemented wait_for in 3.12 [4], and
aiorpcx.timeout_after in 3.8-3.10.

[0] python/cpython#86296
[1] https://bugs.python.org/issue42130
[2] https://bugs.python.org/issue45098
[3] kyuupichan/aiorpcX#44
[4] python/cpython#98518

`asyncio.wait_for` creates another tasks which leads to some race conditions in cancelation and a performance hit

cpython 3.12 will change the underlying implementation of `asyncio.wait_for` to use `asyncio.wait` but that is still a long way off for many people:

python/cpython#98518

* Switch usage of asyncio.wait_for to async_timeout

`asyncio.wait_for` creates another tasks which leads to some race conditions in cancelation and a performance hit

cpython 3.12 will change the underlying implementation of `asyncio.wait_for` to use `asyncio.wait` but that is still a long way off for many people:

python/cpython#98518

* adjust ci

This is an implementation of Python's `asyncio.timeout()` which was introduced
in 3.11. We strongly encourage the use of the following approach instead of
`asyncio.wait_for()`.

    async with timeout(delay):
      # Your async code

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This is an implementation of Python's `asyncio.timeout()` which was introduced
in 3.11. We strongly encourage the use of the following approach instead of
`asyncio.wait_for()`.

    async with timeout(delay):
      # Your async code

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch implements `asyncio.timeout()` which was introduced in 3.11, as well
+as `asyncio.wait_for()` on top of it.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch implements `asyncio.timeout()` which was introduced in 3.11, as well
+as `asyncio.wait_for()` on top of it.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch implements a custom `asyncio.wait_for()` on top of an also custom
`asyncio.timeout()`. `asyncio.timeout()` which was introduced in 3.11.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch implements a custom `asyncio.wait_for()` on top of an also custom
`asyncio.timeout()`. `asyncio.timeout()` which was introduced in 3.11.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch uses `wait_for2` package to implement `asyncio.wait_for()` for
Python < 3.12.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

This patch uses `wait_for2` package to implement `asyncio.wait_for()` for
Python < 3.12.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

`SimpleAsyncQueue.put()` accepted a `capacity` parameter but never enforced it — items were appended unconditionally, making the queue effectively unbounded and defeating backpressure.

Added `_not_full_futures` to block `put()` when the deque reaches capacity, mirroring the existing `_not_empty_futures` pattern in `get()`. Updated docstring to document why this class exists (Python < 3.12 `asyncio.wait_for` item-swallowing bug, python/cpython#98518).

Updated `test_queue.py` with assertions that `put()` blocks at capacity and resumes after `get()`.

* Fix `SimpleAsyncQueue` missing capacity enforcement

`SimpleAsyncQueue.put()` accepted a `capacity` parameter but never enforced it — items were appended unconditionally, making the queue effectively unbounded and defeating backpressure.

Added `_not_full_futures` to block `put()` when the deque reaches capacity, mirroring the existing `_not_empty_futures` pattern in `get()`. Updated docstring to document why this class exists (Python < 3.12 `asyncio.wait_for` item-swallowing bug, python/cpython#98518).

Updated `test_queue.py` with assertions that `put()` blocks at capacity and resumes after `get()`.

* Use self._loop consistently, assert on capacity invariant

* Rename variables for consistency with `asyncio.Queue`

* Fix putter starvation in SimpleAsyncQueue

A new `put()` could steal a slot freed by `get()` before a waiting putter had a chance to resume, starving earlier waiters indefinitely.

Replaced `len(deque)`-based capacity check with a `_size` counter that tracks claimed capacity (items in deque + slots reserved for woken putters). `get()` only decrements `_size` when there are no waiting putters; otherwise it transfers the slot directly to the next waiter. This guarantees FIFO ordering and prevents starvation.

* Assert size. Add clarifying comment.

---------

Co-authored-by: Gal Topper <galt@iguazio.com>

This patch uses `wait_for2` package to implement `asyncio.wait_for()` for
Python < 3.12.

In Python 3.12, `asyncio.wait_for()` is implemented in terms of
`asyncio.timeout()` which fixed a bunch of issues. However, this was never
backported (because of the lack of `async.timeout()`) and there are still many
remainig issues, specially in Python 3.10, in `async.wait_for()`.

See python/cpython#98518

wasted some time because asyncio.wait_for() was suppressing cancellations. [0][1][2]
deja vu... [3]

Looks like this is finally getting fixed in cpython 3.12 [4]
So far away...
In attempt to avoid encountering this again, let's try using
asyncio.timeout in 3.11, which is how upstream reimplemented wait_for in 3.12 [4], and
aiorpcx.timeout_after in 3.8-3.10.

[0] python/cpython#86296
[1] https://bugs.python.org/issue42130
[2] https://bugs.python.org/issue45098
[3] kyuupichan/aiorpcX#44
[4] python/cpython#98518