feat: 166: Proxy support

[nmische]

This PR removes the custom dialer used by grpcurl such that the default grpc-go dialer is used. The default grpc-go dialer supports proxy configuration similar the net.http package (e.g. ProxyFromEnvironment).

I'm assuming this is a safe change as all the tests continue to pass and I can now use the HTTPS_PROXY environment variable to route grpcurl calls through a proxy. That said, it is not clear to me why a custom dialer was used in the first place, so it is possible I am missing something here. (Based on my reading of the code, the custom dialer doesn't seem to add any additional functionality above and beyond a default net.Dialer.)

I have been using grpcurl for a couple of years now, but have only recently needed to use it with a proxy, so I would appreciate any feedback on this PR. Thanks!

Addresses #166

[dragonsinth]

@jhump you probably have the most context on the custom dialer... maybe there was a desire to intercept dial errors here?

[nmische]

Thanks for the quick feedback @dragonsinth! I had a similar thought, but I believe any dialer errors would be handled in a similar fashion (via writeResult()) here.

Unfortunatley the default grpc-go dialer is in an internal package, so if there is a desire to keep this error handling here I think the grpc-go dialer code would need to be ported over to grpcurl. I actually started down that path before opting for this approach. I would be happy to submit that PR as well if it would help evaluate how to address this feature request.

[dragonsinth]

Let's see if jhump has some "context" on this :)

[nmische]

Hi @dragonsinth and @jhump, I went ahead and posted PR #481 which hopefully helps determine a path forward for proxy support gprcurl. Thanks!

[stuartcarnie]

I reverted this patch and it resolves #496