Add HTTP Connect proxy support

[amir-khassaia]

Raising this as a request to support connections via HTTP forwarding/tunneling proxies in addition to SOCKS proxies that are already natively supported. It seems that other paho flavours already have support for this too.

It's possible to work with proxies better by supporting connection tunneling offered by HTTP/CONNECT for compatible proxies as defined in https://tools.ietf.org/html/rfc7231#section-4.3.6.

This works by having the compliant proxy transparently relaying the data and the client issues the connect just writes the data to the proxy without needing to know much more.

Can submit a PR, I've not yet signed an ECA as a contributor though.

Related to #394

[MattBrittan]

Please feel free to submit a PR, however it will not be possible to accept it until you have signed the ECA (it's a fairly simple process and is important in order to ensure the code is appropriately licensed).

[amir-khassaia]

@MattBrittan: I've created an account and signed an ECA against the same github account as I'm pushing from.
However I'm not able to push a new branch to the remote with changes for PR

remote: Permission to eclipse/paho.mqtt.golang.git denied to amir-khassaia.

[MattBrittan]

@amir-khassaia you will not be able to push a branch to this repo; the standard process is to create a fork and generate the pull request from that

[amir-khassaia]

PR done but ECA doesn't appear to be recognized - I've signed and resigned the ECA and double checked the emails match. Will revisit again later.

[MattBrittan]

I can see that you have signed the ECA - there have been some changes made to the ECA verification recently (sign-off within comment no longer needed) so it's possible that this is broken (I cannot see anything obviously wrong). Given that I have no issues with the ECA but have made a few comments (am concerned about adding more complexity into this package, especially when there are side effects like in http_proxy.go. As I see it the user could do this in their own code (we could add a demo that includes this) and that avoids adding it here.

[amir-khassaia]

Agree, I've left comments along the similar thinking in the PR too: #497 (comment)
All this should become is:

• having the proxy example included
• A new callback that will be executed prior to making the TLS handshake to allow SNI injection
  The above will satisfy all the use cases whilst keeping the library clean.

[amir-khassaia]

Reworked the PR to adhere to the above discussion

[amir-khassaia]

Resolved in #497, closing.