MINA proxy handshake fix and proxy integration tests

[the-thing]

Changes

• added custom SSL wrapper to fix proxy connectivity before official MINA patch
• removed unused PROXY protocol type
• added SOCKS proxy server (via Netty)
• added Maven build extension to help build tests using Netty
• added SSL and non-SSL integration tests

[chrjohn]

@the-thing , thanks for the PR 👍
On another note: do you know if #631 could be related?

[the-thing]

That's a different problem and not related to the current MINA issue.

https://github.com/apache/mina/blob/2.2.X/mina-core/src/main/java/org/apache/mina/proxy/handlers/http/HttpSmartProxyHandler.java

When MINA's HTTP proxy handler does the handshake, the proxy server can respond with "407 - Proxy Authentication Required" status code which will make MINA's handler to automatically switch and choose HTTP auth method based on the response (no-auth, ntlm, digest and basic) and populate headers. However, I assume this might not be the case for all HTTP proxy servers and some some of them might require you to know the auth method in advance and you must ensure that headers are already populated. Hence the fix is required.

I think #631 looks reasonable, but we don't have HTTP tests yet so we don't know if this works. Also one thing about PR - the auth method is chosen based on properties provided, but I have a feeling that HTTP auth method should be configured explicitly.

[chrjohn]

I suppose this is ready to merge?
Thank you as always 👍

[the-thing]

Yes, it is. No problem.

BTW. Is VM_PIPE still supported and working?

[chrjohn]

It was used for unit tests some time ago and works AFAICT. I only had the suspicion that it sometimes hung the connector during the acceptance test run where the connectorwas started and stopped in quick succession. But I never followed it up.

[the-thing]

I was just wondering if this should be removed at some point. I have a feeling that nobody uses it.

[chrjohn]

Is it complicating the code much? I don't know if it has performance benefits when connecting intra VM. It was said it has but that was some years ago.

[the-thing]

I don't think so, but could be slightly cleaner. Functionally it might have some benefits, but I don't really know how this works. I was more thinking about removing so "SocketConnectProtocol" parameter goes away and we end up with less config. Still probably not a target for this PR.

[chrjohn]

Maybe we could (if it is not already the case in the code) assume TCP as default so one does not explicitly need to define the parameter.