experiment in proper handling of HTTP/HTTPS proxy env vars

[JPDye]

#1134

Ureq doesn't properly respect the HTTP_PROXY and HTTPS_PROXY env vars, both in their ordering and with respect to traffic types (HTTP_PROXY is only for HTTP traffic, HTTPS_PROXY is only for HTTPS traffic).

This PR is the result of me messing around with how to support the above. I've added two proxies to the Config and pick between them based on the target the Request is being sent to. Happy to make any and all changes, this is really just a messy draft.

Run the proxy example and look at your local proxy to see two requests sent through two different proxies.

[JPDye]

While making these changes, I noticed ureq uses CONNECT tunnels for both HTTP_PROXY and HTTPS_PROXY proxies. Typical behaviour with tools like CURL is to not use CONNECT tunnels for the HTTP_PROXY.

[algesten]

While I believe this PR is making things more correct, it's also a somewhat breaking change – though correcting bugs is ok without a major revision.

To be clear against users, I believe we should include this in a minor revision. ureq 3.2

[JPDye]

Sorry, forgot about this. Only remembered when you mentioned this env-var issue in the netsack podcast. So... what's stopping this from being merged (aside from it still being messy and in need of cleanup)? If it's breaking changes, I think there's ways to mitigate that.

I think fixing the env-var fallback issue is much less likely to cause issues for existing setups than the usage of those vars to send HTTP traffic to HTTP_PROXY and HTTPS traffic to HTTPS_PROXY. I could separate the env-var fix and traffic type fix into different PRs.

While making these changes, I noticed ureq uses CONNECT tunnels for both HTTP_PROXY and HTTPS_PROXY proxies. Typical behaviour with tools like CURL is to not use CONNECT tunnels for the HTTP_PROXY.

^ As for this, I've got a separate branch that fixes this issue and I'll make that PR soon.