fix: disable multiplexing for some versions of curl by weihanglo · Pull Request...

What does this PR try to resolve?

Fixes #12202.
Zulip topic.

In certain versions of libcurl when proxy is in use with HTTP/2
multiplexing, connections will continue stacking up. This was
fixed in libcurl 8.0.0 in curl/curl@821f6e2

However, Cargo can still link against old system libcurl if it is from a
custom built one or on macOS. For those cases, multiplexing needs to be
disabled when those versions are detected.

How should we test and review this PR?

The first commit refactors how Cargo gets http.proxy config, so that
wecan have the detection inside Config. Please call it out if you
feel uncomfortable to this.

The second one did the trick, and a unit test is added.

Manual test the behavior

To manually test the behavior, you need to build cargo with
the all-static feature, which despite its name links libcurl
dynamically on macOS. It is a feature used by rustup distributions.

cargo b -F all-static

I don't really understand curl internals so had no luck to figure
out the relationship between proxies and HTTP/2 multiplexing.
I use hinata/nginx-forward-proxy to spin up a proxy to test curl's behavior.
It turns out that if there are fewer dependencies to download,
or we set MAX_CONCURRENT_STREAMS to a lower value in curl,
it largely affects the happening of the error no filter connected.

That implies multiplexing and http proxy are really influencing
each other in some way.

index ec9f878b3..3a687c309 100644


 vendored-libgit2 = ["libgit2-sys/vendored"]
 pretty-env-logger = ["pretty_env_logger"]
 # This is primarily used by rust-lang/rust distributing cargo the executable.
 all-static = ['vendored-openssl', 'curl/static-curl', 'curl/force-system-lib-on-osx']





index 7e1f2a587..21ae3ca10 100644


 impl<'cfg> HttpRegistry<'cfg> {
                 .status("Updating", self.source_id.display_index())?;
         }
 


         Ok(())
     }