feat(websocket): Add proxy configuration

[jnugh]

Allow usage of http(s) proxy for websocket traffic

I did not create an issue beforehand but I can create one if this is required.

This change adds functionality to connect to a websocket trough an http proxy (which are sometimes required in corporate environments 😿). It's probably also an interesting feature for debugging as it allows developers to intercept websocket traffic using tools like mitmproxy.

I also added two functions (reconfigure_tls_connector and reconfigure_proxy) as both settings might be changed by the end user - at least in our case. I tried to remove and re-add the plugin but this did not change the internal state as manage checks if an item is already present. I can move those to a different PR or implement this in a different way as well. Just let me know.

[FabianLars]

Thanks for contributing! I'm a bit swamped with v2 stuff and generally aren't experienced with proxies so reviewing may take a while. That said, did you see the PRs for the v2 http and updater plugins?
#824
#891

They allow configuring the proxy on each call from the js side. Does it make sense to follow that approach here too? This wouldn't work for the TlsConnector so i wouldn't mind sticking to a rust-only solution.

[jnugh]

Hi, thanks for the quick reply. Don't worry we are using the PR branch in the meantime. I can rebase this onto v2 if this would be helpful.

Technically the configuration on a per-call basis would work. Even passing the TLS Connector settings would be possible. What we though was basically:
Both settings might contain sensitive credentials and we try not to keep passwords inside the rust context and use the credentials store of the operating system. Having a command to read the password would allow someone with access to the JS environment to read this password as well.

Maybe having both would be a good idea? Defining defaults in the rust context and allow overrides.

[FabianLars]

Both settings might contain sensitive credentials and we try not to keep passwords inside the rust context and use the credentials store of the operating system. Having a command to read the password would allow someone with access to the JS environment to read this password as well.

Yeah, that was my concern as well but seeing the other plugins not caring about it i thought i may not be an issue. Maybe the auditors will scream at us once they look at the plugins too 🙃

Let's keep it on an on-demand basis and stick to rust-only, adding js support once requested.