io.asyncioreactor: fix deprecated usages for working with python>=3.10

[fruch]

• stop using the loop argument for asyncio.Lock and asyncio.Quoue`
• on the lock replace with await with async with, which is the correct
  syntax for using that lock

[Lorak-mmk]

I'm a bit surprised by this merge - I did not review it yet, but I reviewed the previous version, before the split, made some comments and one imo important comment was neither fixed nor responded to.
#260 (comment) - you still call asyncio.set_event_loop(cls._loop) (but now conditionally for some reason) and I still don't see how it makes sense in any scenario.

Also, I proposed an alternative way of dealing with loop argument, and it can be made prettier than the example I posted in previous review, by having sync and async part of init, something like that:

    async def _init_async(self):
        self._write_queue = asyncio.Queue()
        self._write_queue_lock = asyncio.Lock()

and in init call asyncio.run_coroutine_threadsafe(self._init_async(), loop=self._loop).result() in a place where queue and lock were previously initialized.
This has the advantage of not using deprecated arguments ever, so less warnings from driver. And then another one of my comments can be applied: #260 (comment)

[Lorak-mmk]

In push function, self._loop.create_task is called and it's return value is ignored. While the tests may pass now, this code is not correct and this example is called out in docs as a source of bugs: https://docs.python.org/3/library/asyncio-task.html#asyncio.create_task

[fruch]

I'm a bit surprised by this merge - I did not review it yet, but I reviewed the previous version, before the split, made some comments and one imo important comment was neither fixed nor responded to. #260 (comment) - you still call asyncio.set_event_loop(cls._loop) (but now conditionally for some reason) and I still don't see how it makes sense in any scenario.

Taking it completely won't always work, there are cases it can be call while no event loop is define, you can remove it and see it failing the tests

Also, I proposed an alternative way of dealing with loop argument, and it can be made prettier than the example I posted in previous review, by having sync and async part of init, something like that:

    async def _init_async(self):
        self._write_queue = asyncio.Queue()
        self._write_queue_lock = asyncio.Lock()

and in init call asyncio.run_coroutine_threadsafe(self._init_async(), loop=self._loop).result() in a place where queue and lock were previously initialized. This has the advantage of not using deprecated arguments ever, so less warnings from driver. And then another one of my comments can be applied: #260 (comment)

Yeah it might remove the warning, but I just understood what you meant

One still need to get it tested