…#4180)

* feat(ProxyAgent): match Curl behaviour for http-http Proxy connections

Curl does not send a CONNECT request for to a Proxy server, by default,
for cleartext communications to an endpoint, via a cleartext connection
to a Proxy. It permits forcing a CONNECT request to be sent via the
--tunnelproxy parameter.

This change modifies ProxyAgent's constructor to accept a `tunnelProxy`
option, sends a CONNECT if either `tunnelProxy` is true, or either the
Proxy or endpoint use a non-http: protocol.

Disabling tunneling for HTTP->HTTP by default would be a breaking change, so
currently, the tunneling behaviour requires an opt-out. This may change depending
on feedback during code review.

This adds a new test case which explicitly disables tunneling for an HTTP->HTTP
connection, and asserts that no CONNECT message is sent to the server or proxy,
and that the expected HTTP request is sent to the proxy.

Closes #4083

* Part 2

This version tries to expose less sketchiness -- it's not particularly well organized yet, and
I'm sure it could be cleaned up a lot.

Instead of adding the "rawSocket" stuff to RequestOptions, there's a new wrapper ProxyClient added,
which intercepts the CONNECT message and prevents it from being dispatched.

Unfortunately the wrapper client isn't quite written in a way to manage all of the client-ness,
so ProxyAgent is still responsible for updating the PATH of HTTP->HTTP Proxy requests to include
the endpoint domain.

It is messy though, admittedly.

* remove rawSocket from Dispatcher type definition

* Add some docs

* rename to proxyTunnel to match CURL

* Rename  to  in the docs, too

* Try to clarify the docs a bit

initially just wanted to fix a typo, but thought maybe the original explanation wasn't great.

(cherry picked from commit 95fd9d3)