Added an alternate fix for MemoryObjectReceiveStream.receive()` on asyncio

[agronholm]

This fixes #146 properly. Also fixes #536.

[gschaffner]

wow, this is a much simpler technique than my proposed one. thank you!

[gschaffner]

one concern: doesn't this fail when native cancellations are in the mix? for example:

@pytest.mark.parametrize("anyio_backend", ["asyncio"])
async def test_event_wait_before_set_before_asyncio_cancel() -> None:
    # compare this to test_event_wait_before_set_before_cancel.
    waiter_woke = False
    event = anyio.Event()

    async def waiter() -> None:
        nonlocal waiter_woke
        asyncio.get_running_loop().call_soon(setter)
        await event.wait()
        waiter_woke = True

    def setter() -> None:
        event.set()
        # trigger the race condition where cancel() is called before waiter() gets
        # rescheduled
        native_waiter.cancel()

    native_waiter = asyncio.create_task(waiter())
    await native_waiter # raises, but it shouldn't
    assert waiter_woke

(in this example I would expect anyio.Event to still behave like trio.Event.)

this means that if native cancellations are in the mix (e.g. due to third-party asyncio libraries), bugs like #146 (and more generally #536) can still happen.

the approach of #537 doesn't have this problem. (although, #537 only touches Event, and there may be other primitives with similar issues that this patch touches but #537 didn't.)

i suspect that this problem is probably quite rare (although asyncio cancellations might become more common with asyncio.timeout introduced in 3.11?), but it may still be worth mentioning.

[agronholm]

Asyncio's cancellation, as implemented today, is not trivially fixable, and requires some hard decisions upstream. I've had a lengthy post about this in the works for a while which I will post to Async-SIG.