feat(iroh-net)!: Implement http proxy support

[dignifiedquire]

Headers are based on how curl and env variables onreqwest.

Setting any of

• HTTP_PROXY
• http_proxy
• HTTPS_PROXY
• https_proxy

will make all relay code use these to proxy outgoing connections.

Closes #2295

Breaking Changes

• Added iroh_net::endpoint::Builder::proxy_url
• Added iroh_net::endpoint::Builder::proxy_from_env
• Added iroh_net::relay::http::ClientError::Proxy enum variant

TODOs

•  config & parsing env variables
•  the todos in the code
• https proxy
• testing: tested manually on two machines using squid

[link2xt]

Is it a good idea for a library to read environment variables? I think application should do this, there are more variables like NO_PROXY and at least in GNOME proxy is expected to be controlled via org.gnome.system.proxy. On other platforms proxy may be controlled differently as well.

[dignifiedquire]

Is it a good idea for a library to read environment variables?

reqwest is already used, and does exactly this. They do cover a wider variety of supported variables, like NO_PROXY and system specific configurations which we can add over time, but for now this allows existing users who need this to work with iroh, where they can't currently

[zicklag]

Environment variables for proxy configuration are extremely common. curl, wget, apt and more support the environment variables. Almost every tool that supports proxies supports it through environment variables, especially if it has a CLI.

Fundamentally I think it makes sense because it is an environment configuration, that is the same for every tool on the machine, in almost every case, and it doesn't seem valuable to make the user comprehend separate configurations for every app they use that needs to access the network if it isn't necessary.

[link2xt]

Environment variable configuration is fine, but I think it should not be done by the libraries. If every library that does networking implements proxy variable parsing, then you will get slightly different handling of these environment variables within a single application: some libraries parse only uppercase variables, some handle NO_PROXY and some don't etc.

Environment variables also have a downside that they cannot be reconfigured in runtime, so in Android applications you probably want to have some hooks that detect network changes, on desktop Linux you want to hook into NetworkManager changes because proxy may be needed in a corporate VPN and not even accessible outside this VPN. This kind of hooks/reconfigurations better happens on the application side because Rust libraries may not even be able to access necessary Java APIs on Android.

Parsing environment variables in reqwest is a bad decision IMO, somewhat similar to libraries that log error messages to stderr.

[zicklag]

I see your point.

Maybe we should have a Proxy config struct that could be passed into the ClientBuilder or something like that. We could have a Proxy::from_env() function, and you could have proxies disabled by default in the library.

Then the Iroh CLI will configure the client with the Proxy::from_env().

It would actually be handy to have the Proxy struct, and the environment variable parsing logic in a separate crate so that it could be re-used.

[dignifiedquire]

the environment now needs to be read explicitly in iroh-net, but iroh will by default read it

[flub]

I like the approach of the builder in Endpoint. Only minor note I have is that we now have two pin-project crates...

[zicklag]

Thanks a bunch for this work. ❤️