`http_get()`/`http_post()` ignore `http_version` and always use HTTP/2

[Felixmil]

Requests and downloads build their curl options through different helpers, and they disagree on http_version:

• Downloads (download_file() etc.) go through update_async_timeouts(), which sets http_version (default default_http_version(): HTTP/1.1 on macOS/Linux, NONE on Windows).
• Requests (http_get(), http_post(), http_head()) go through get_default_curl_options(), which sets timeout/connecttimeout/cainfo but never http_version.

So plain requests always use libcurl's default (HTTP/2), on every platform, and neither PKGCACHE_HTTP_VERSION nor async_http_http_version reaches them, there is no way to pin a request to HTTP/1.1.

This bites API queries that flake over HTTP/2 (connection reset / GOAWAY) on some client stacks. A concrete case: pkgdepends' GitHub GraphQL query (api.github.com/graphql via http_post()) fails at the transport level with no HTTP-version knob to work around it, while downloads to the same host are pinned to HTTP/1.1 and fare better.

Note: default_http_version() returns NONE (HTTP/2) on Windows, so honoring http_version on the request path alone would still leave Windows on HTTP/2 unless the Windows default is also revisited or callers can force HTTP/1.1 explicitly.

following r-lib/actions#1091

[gaborcsardi]

I am fairly sure that the crux of the problem is that the connection is reused for a POST after a very long wait, because GH closes down the connection after 10-20s (?) of inactivity. libcurl retries GET requests automatically, but not POST requests. E.g. you have a direct GH dependency which also has a downstream GH dependency, and you also use multiple repos, e.g. PPM and Bioconductor.

Nevertheless HTTP 1.1 has different multiplexing so it is very possible that it solves the symptoms, and that option should apply all HTTP requests anyway.