Deprecate async_generator

[pquentin]

Now that Python 3.6 reached EOL, I believe this library does more harm than good and we should deprecate it and eventually archive it. What do you think?

[geofft]

I was just about to file an issue asking if you were considering this. I think it'd be worth
a) making the README and the doc home page clear about what async_generator is - something like "async_generator was written as a compatibility library for Python 3.5 to support this and that... it also backports contextlib.asynccontextmanager for Python 3.5 and Python 3.6. If you're on Python 3.7 or newer, you do not need this library at all and should not use it." Right now it kind of dives into the mechanics.
b) removing documentation references in other projects (e.g. https://pytest-trio.readthedocs.io/en/stable/quickstart.html#async-fixtures) to async_generator

and yeah, formally marking it deprecated seems fine. As a data point, the latest NumPy release dropped 3.7 support, so I think you're justified dropping a library that exists mostly for 3.5 and slightly for 3.6 :)

[webknjaz]

FTR async_generator is experiencing problems under Python 3.11. I didn't look deep into it and removing it and replacing stuff with native syntax helped. (We had it integrated into aiohttp's tests to support Python 3.5 years ago but forgot to drop from some release streams when it was no longer necessary)

[belm0]

Now that Python 3.6 reached EOL, I believe this library does more harm than good and we should deprecate it and eventually archive it.

reminder that this library exports aclosing(), which wasn't added until Python 3.10

[opoplawski]

Tests are failing with Python 3.12. Worth keeping this around or just dumping it?

[jakkdl]

Tests are failing with Python 3.12. Worth keeping this around or just dumping it?

it should probably be kept around for the sake of aclosing() until py310 EOL - but could raise deprecation warnings on everything else in it.