feat: Add Web Socket Forwarder from connection Web Client to Agent for HTTPS support

[hazmi-e205]

Whether this PR is eventually merged or not, Sonic will thank you very much for your contribution.

无论此PR最终是否合并，Sonic组织都非常感谢您的贡献。

Checklist

• [x] The title starts with fix, fea, or doc. | 标题为fix、feat或doc开头。
• [x] I have checked that there are no duplicate pull requests with this request. | 我已检查没有与此请求重复的拉取请求。
• [x] I have considered and confirmed that this submission is valuable to others. | 我已经考虑过，并确认这份呈件对其他人很有价值。
• [x] I accept that this submission may not be used. | 我接受此提交可能不会被使用。

Description

Due to connecting the Web Client to the Agent directly is pretty hard when it is published in HTTPS, We create a web socket forwarder, so the connection will be converted from "wss://" to "ws://".

[ZhouYixun]

@hazmi-e205 Thank you for your code! But the front-end should change the ws url, I think you are missing the sonic-client-web pr, right?

[ZhouYixun]

In fact, forwarding the Agent's data traffic through the server is not the most ideal result, which will make the delay larger.

[yaming116]

All network traffic passing through the server will increase the network pressure and service delay on the server side. The agent needs to upload data to the server, and then the user receives the traffic data from the server. The entire link will be much longer, and the agent needs to have sufficient upload bandwidth and the server has sufficient downlink bandwidth. If you need the agent to support SSL configuration, you can add nginx in front of the agent, and then resolve it to the intranet IP during domain name resolution.

[hazmi-e205]

@yaming116 have you ever tried it? Actually, last time I tried was switch the agent to HTTPS and the WebSocket upgraded to WSS successfully but the problem is Sonic Client Web can't connect to WSS URL without clear error message.

Here our discussion https://discord.com/channels/1182530185749344307/1193785848223760464

[hotsmile]

All network traffic passing through the server will increase the network pressure and service delay on the server side. The agent needs to upload data to the server, and then the user receives the traffic data from the server. The entire link will be much longer, and the agent needs to have sufficient upload bandwidth and the server has sufficient downlink bandwidth. If you need the agent to support SSL configuration, you can add nginx in front of the agent, and then resolve it to the intranet IP during domain name resolution.

but ，you can't use wss to remote link to the terminals, right?

[hotsmile]

All network traffic passing through the server will increase the network pressure and service delay on the server side. The agent needs to upload data to the server, and then the user receives the traffic data from the server. The entire link will be much longer, and the agent needs to have sufficient upload bandwidth and the server has sufficient downlink bandwidth. If you need the agent to support SSL configuration, you can add nginx in front of the agent, and then resolve it to the intranet IP during domain name resolution. but ，you can't use wss to remote link to the terminals, right?