Adding httpcore.AsyncIOBackend().

[tomchristie]

Initially httpcore used an asyncio and a trio implementation for the two different async cases.

We later switched the asyncio case out to use anyio. This was motivated by a few wrinkles in asyncio at the time, that anyio did a good job of resolving. (Are we able to dig out any good history on this? What's the commit when we dropped the asyncio-based implementation and switched to anyio as the default?)

Since it's been a while I suspect that some of the bugs we were running into may have been resolved in the stdlib now. Should we add a native httpcore.AsyncIOBackend() again now?

• Since we've got the network backends documented we could add one even if it's not the default. Allows us to test out any awkward asyncio networking buglettes with alternative implementations, which is often a useful narrow-this-down-for-me-tool.
• We could review and more throughly document our motivations in having an anyio based implementation.
• We could reconsider if our at-the-time motivations are still valid now, with the option of switching back to an asyncio native implementation, for a lighter dependancy footprint.

[zanieb]

Just wondering, why do we have a trio native implementation rather than just using anyio for both the asyncio and trio cases?

[tomchristie]

So, it's partly historical... If anyio had been a mature project we might not have started out with asyncio and trio variants, and we might have decided to just stick with a single async backend.

But also if I was working with trio, I'd much rather have a trio-native backend.
Neater tracebacks, and no in-between layer needed.