Create Network Troubleshooting section that would help users find solution if WebSockets are blocked

[sleshchenko]

Is your enhancement related to a problem? Please describe.

Some VPN blocks WebSockets and then Che becomes unusable since Che Theia really rely on WebSockets for communication between Client and Server sides.

Describe the solution you'd like

The suggestions:

• Absolutely put some obvious error detection and informational messaging for the end-user to consume when web sockets is a problem. This will help them from banging their head against a brick wall refreshing their browser. The half-drawn IDE with hanging red C symbol we currently have is not great UX.

  • The dashboard is supposed to show banner after Show the warning message about failing WebSocket connection che-dashboard#72
  • Do we need Theia to check it on its ide?

• Provide useful suggestions to the end user - now this might be tricky, since “Switch off your VPN” or “Disable local firewall" is never going to be reasonable option in a corporate deployment however suggesting this is a network, firewall, VPN or proxy issue might be a useful clue about who to report this problem to.

• Some suggested links on how to configure VPN, firewalls, proxies etc. These maybe third party, but we should be trying to collect some resolutions stories that we can share as a guide to the network team particularly if they are not familiar with wss. If we can also find some security articles that are positive about websockets they would also be useful to share.

• It would be really useful to run or recommend a 3rd party web site that has wss content that can be used as a test site with no login wall (like https://websocketstest.com/). So if this site works, then Che should be fine. That allows any network engineer to have something to resolve against without needing access to Che.

• Document the network requirement in the Che Installation/Admin guide so there is at least a section highlighting this.

[RickJWagner]

Thank you for this good idea, it seems it will be very useful.
In writing the error messages, could we please be specific about which websocket endpoint is having trouble connecting to which other endpoint? (Identify the targeted component in easy to recognize terms.)
The reason for this request: sometimes environments are not homogenous (i.e. on AWS different Che containers may end up in different 'Availability Zones'). Things like that can make network debugging mysterious, but if we know from the error message exactly where we are trying to get to, it can be a good head start.

[olexii4]

Fixed with eclipse-che/che-docs#1445