…into a conversation.

===

Fixes #2144

===

This issue was a Windows-only (possibly Linux as well) bug that was happening due to the following:

1. The Emulator (on Windows) parses deep links / protocol URLs after we receive an event from the client saying that the Welcome page has rendered
2. This step happens before the browser window ready-to-show event is fired, and so before the WebSocket server is initialized
3. The start conversation action dispatched by the protocol URL in step 1 then triggers the start conversation flow which eventually makes a call to the getWebSocketPort route
4. The getWebSocketPort route starts the websocket server if not already running, and then returns the port. In the deep linking case, this always starts the server
5. The conversation with Web Chat is started with a successfully connected websocket
6. The ready-to-show browser window event is then fired and the web socket server is re-initialized which then calls cleanup(), closing the previously connected websocket for the running conversation
7. now messages do properly flow out of WebChat, through the emulator, to the bot, and back to the emulator, but the websocket is no longer there to complete the trip to WebChat
8. This results in a broken WebChat UI where none of the messages are seen as "sent" and none of the bot responses are rendered

===

This PR fixes that issue by changing the websocket server logic to only initialize the server once and return the port, instead of re-initializing if already running.

This means that the second call to WebSocketServer.init() in step 6 above results in a no-op and instead just returns the websocket server port.

===

This does not occur on Mac because the protocol URLs are parsed and executed after the initial setup of the websocket server inside of the ready-to-show browser window event handler