Warn, or callout in connection error, when using insecure websockets

[mcclure]

js-libp2p-webrtc-star and js-libp2p-websockets both support either ws/ or wss/ multiaddrs (WebSockets, or SSL WebSockets). Many of the examples, such as libp2p-in-the-browser or peer-and-content-discovery, use vanilla WebSockets, not Secure WebSockets, and this is appropriate, since these examples are likely tested using web servers on localhost and it is difficult to set up SSL on localhost.

However, insecure WebSockets is unpredictable. Leaving aside the question of whether insecure websockets "should" be used, attempting to use insecure WebSockets in a browser may sometimes fail just because it is insecure, for example:

• The libp2p-in-the-browser example is deployed to an HTTPS server. The browser blocks it because accessing insecure websockets is a mixed-content violation.
• Something I saw myself last night: I have a libp2p-in-the-browser based demo (see js-libp2p-kad-dht bug 221) that could successfully connect two peers to each other behind NAT using a personal VPS as a signaling server. Last night, this demo worked. This morning, it was failing with error "Transport (WebRTCStar) could not listen on any available address". The reason for the failure: Sometime around 10 PM last night I accessed the VPS where the signaling server in an ordinary browser tab, which activated HSTS for the entire domain, including the signaling port. That's pretty subtle.

These failures can be based on unpredictable local state (browser, HSTS state). If a user encounters one of these failures, they are unlikely to easily figure out on their own why the failure occurred: The change is something sort of nonobvious (change "/ws" in the listening list to "/wss") and making it work requires something the examples don't include (setting up SSL, libp2p has a out-of-the-box docker for a nginx proxy to do this but it isn't part of the examples directory). This is demonstrably a support issue for libp2p (searching google for the error messtingges I get when hitting insecure websockets problems I find many cases, including on https://discuss.libp2p.io/, where a libp2p core dev is having to explain that setting up SSL is needed).

A suggestion: When sending in /ws multiaddrs for listen or bootstrap in a browser, do one of the following:

1. Print a warning to console warning that insecure websockets may not work in all browsers.
2. Remember that an attempt was made to connect to insecure websockets. If after this an exception is thrown which could be the result of the browser cutting access to insecure resources (for example, say "Transport (WebRTCStar) could not listen on any available address" is thrown after an unsuccessful attempt to listen: for a /ws signaling server), include in the exception message "(This browser might be blocking insecure websockets)".

Since this case will mostly only come up in test/example projects, console noise is probably acceptable. If console noise is a concern, there could be a Libp2p.create() flag to disable insecure-websockets warnings.

Note: Maybe a similar issue should be filed on js-libp2p-websockets, I don't know.

[BigLep]

Thanks @mcclure for reporting. Would you be interested in making the change to print the warning in the console? This would be in libp2p/js-libp2p-websockets.