add httpxyz fallback for async HTTP

[tobixen]

httpxyz is a maintained fork of httpx (https://codeberg.org/httpxyz/httpxyz)
that picked up where httpx stalled. Fallback priority is now:
niquests (preferred) → httpxyz → httpx

• Add _USE_HTTPXYZ flag alongside existing _USE_HTTPX/_USE_NIQUESTS
• Import httpxyz as httpx so all existing httpx.* calls work unchanged
• Add httpxyz to optional [test] deps in pyproject.toml
• Add async-httpxyz and async-httpx CI jobs to verify each fallback path works
• Update async-niquests CI job to also uninstall httpxyz before the run

Fixes: #611

prompt: Look into issue #611 - we will need to support fallback to the httpxyz library. httpxyz should be preferred to httpx. And we need some basic workflow tests on github that all those fallbacks work.

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

[tobixen]

(last force-push edited the commit description only)

Is this sufficient for you, @lilydjwg ?

[lilydjwg]

Hi, there is some misunderstanding. I participate in the HTTP library discussions only because I'm looking for ideas on the topic from other people / project. I do not actually use caldav.

(I found here by web search, and I'm a little surprised that not a lot people discuss which HTTP library to use.)

[tobixen]

(... I'm a little surprised that not a lot people discuss which HTTP library to use.)

The regular requests and httpx libraries works well enough for the very most use cases, and so far there hasn't been any widely known security vulnerabilities on those libraries. Most people have no reason to ask questions. requests and httpx are the go-to libraries that they know, it's the libraries that would be suggested by the AI (because "everybody else" are using them), it's the libraries that would be showing up in google searches, it's the libraries a friend would recommend (because he has been using it for ages without considering the existence of better alternatives), it's the libraries one would find when looking into "how is this done in other python software products?"

Every now and then someone gets bitten by the lack of default timeouts in requests (inevitably causing some application to hang infinitely waiting for a reply from a stale TCP connection and things like that) or starts wondering why the traffic still flows over HTTP/1.1 when HTTP/2 or even HTTP/3 has become the industry standard. 90% of those people would just shrug, thinking "I'll just define my own timeouts" or "HTTP/2 will certainly be supported next year".

This leaves very few left to question the status quo.