Removed insecure upstreams check

[Saiv46]

Dockerfile

FROM caddy:builder AS builder
RUN xcaddy build \
    --with github.com/caddyserver/forwardproxy=github.com/saiv46/forwardproxy@patch-1
FROM caddy:latest
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

1. What does this change do, exactly?

Removes insecure schemes are only allowed to localhost upstreams, because it prevents using upstreams in Docker containers.

2. Please link to the relevant issues.

Resolves #116

3. Which documentation changes (if any) need to be made because of this PR?

- Supported schemes to remote host: https.
- Supported schemes to localhost: socks5, http, https (certificate check is ignored).
+ Supported schemes: socks5, http, https (certificate check is ignored for localhost).

4. Checklist

• I have written tests and verified that they fail without my change
• I made pull request as minimal and simple as possible. If change is not small or additional dependencies are required, I opened an issue to propose and discuss the design first
• I have squashed any insignificant commits
• This change has comments for package types, values, functions, and non-obvious lines of code

[zoulja]

Does anybody know what must be done to accept this PR?

[cachius]

Does anybody know what must be done to accept this PR?

Probably @mholt.

I imagined to put the new behaviour behind a switch, maybe.
Am not sure whether CONNECTing to the upsteam HTTP proxy requires extra implementation.

[mholt]

Unfortunately I don't think I'm qualified at this time to decide whether this change is a security risk or is the correct thing to do. (see #116 (comment)). I am just not familiar enough with the code base / threat model, and don't really have the time at the moment. Anyone else is welcome to investigate though!

[francislavoie]

I would suggest the check stays by default, but a config property should be added to optionally disable this check. Like a disable_insecure_upstreams_check Caddyfile option.

There are legitimate usecases where sending out HTTP through the proxy is useful, for example using forwardproxy as a tool for connection pooling for an app that isn't able to do pooling itself, where some requests may go out to other internal services in the LAN.

[francislavoie]

If you don't mind I'll rework this as I suggested in a separate PR (just to get it done with)

#149

[mholt]

Thank you for taking initiative on this, @Saiv46 and @francislavoie