Fix a websocket connection issue when running in the proxy mode

[wandrien]

Steps to reproduce:

1. Run Zeronet with --ui_trans_proxy in a docker container or other isolated environment.
2. Set 127.0.0.1:43110 as a HTTP Proxy in a browser.
3. Navigate to http://talk.zeronetwork.bit/
4. The site stops loading, since the websocket connection isn't functional.

The bug consists of 2 related issues:

1. Connect to the proper address.

   When running in the proxy mode, Zeronet sends its env["SERVER_NAME"] and env["SERVER_PORT"] as the websocket destination address in the wrappper HTML code (variable server_url). That looks wrong for me, since the values of those variables have nothing to do with the actual address accessible by the browser. ZeroNet can run in a container, the connection also can be tunneled over SSH and so on. In all those cases, the internal SERVER_NAME makes no sense as the destination at all.

   The code for sending and handling server_url is deleted. The browser should connect to the websocket in the same way as it connects to the ZeroNet UI in general.

2. Send the proper response for CONNECT requests.

   A browser tries to connect to the correct address, but it still fails. A browser, when connecting via a HTTP proxy to a webdocket, uses the HTTP tunneling protocol, and ZeroNet lacks support for it. To fix this, it's enoght to send the "200 OK" response on the CONNECT method request.

[wandrien]

We still have some bugs here.

UiRequest doesn't allow what it should:

http://zero/1HeLLo4uzjaLetFx6NH3PMwFP3qbRbTf3D/ returns "Forbidden"

And allows what it shouldn't:

CONNECT accepts just any connection. So Firefox tryes to open SSL connections to *.firefox.com and sends encripted garbage there.

But this should be fixed in a different pull request, I guess, as it affects other parts of UiRequest.