Don't force HTTP/2

[Shnatsel]

Checklist

• I have read the Contributor Guide
• I have read and agree to the Code of Conduct
• I have added a description of my changes and why I'd like them included in the section below

Description of Changes

Do not force HTTP/2. Corporate transparent proxies often do not support it, but cargo audit needs to run in these environments.

After this change HTTP/2 will be used where available, but the download will not fail if it's not.

Related Issues

rustsec/rustsec#988

[Shnatsel]

Curiously I'm not seeing a regression in fetch times for the sparse index even when I force HTTP 1.x. You'd think it'd be slower because we're missing out on multiplexing, but apparently not.

[Jake-Shadle]

I'd be interested to see if this affects throughput, as I believe now it has to/might do an extra round-trip if the remote server is HTTP/2?

Regardless, it's a shame that antiquated corporate environments negatively? Impact all other users.

[Jake-Shadle]

I believe it does a round-trip to upgrade, but maybe it caches that for the client so doesn't impact each unique request.

[Shnatsel]

I agree this is unfortunate. It would be nice to try HTTP/2 first, but corporate proxies just blackhole the request instead of replying with "505", so that would cause every request to first time out for 10 seconds and only then fall back to HTTP 1.1. So I'm afraid that's untenable.

Since it's possible to supply a custom Client, use cases where avoiding a roundtrip is preferable to wide compatibility can force HTTP/2 in the client builder. I don't think that should be the default though - things actually working is generally preferable to slightly higher performance.