fix: streaming client should connect under Node.js

[compulim]

Fixes #4412.

Description

NodeWebSocket.connect() is not implemented correctly and should never work. There are multiple problems in the original implementation:

• It expects the first argument is hostname
  • Instead, it should be server URL (for example, ws://your-bot.azurewebsites.net/.bot/v3/directline?token=123)
• It is using a server, fake handshake, to get the WebSocket object out, which is probably not working
• It is waiting for close event for connection to established, which is wrong

We are not sure why the original implementation has done this way.

We are updating the implementation to use ws package to connect.

Designs

Removing second argument (port = 8082)

We are removing the second argument (port = 8082) because:

1. The serverAddress will contain the port number (by default, ws: is 80, and wss: is 443)
2. If we keep the current logic, we will always ignore the port number in serverAddress because port is default to 8082

This does not sound intuitive to developer because the port number in serverAddress will always get replaced.

If we don't default port number to 8082, we will need to change the API saying there is no default (i.e. undefined). At the end of the day, we are still modifying the API and will introduce breaking changes.

Regardless of whether we keep port or not, we are still introducing breaking changes. Thus, we are choosing to remove port to simplify our code.

If the developer need to change the port to 8082, they could use the following code snippet:

const url = new URL(serverAddress);

url.port = 8082;

await nodeWebSocket.connect(url.href);

Specific Changes

❗This PR will introduce breaking changes and modified the API. Please bump version appropriately.

• Update NodeWebSocket.connect() to connect to a Web Socket server as a client
• Add tests
  • We did not add unhappy path (connect() rejections) because it will print errors to console and there is no easy way to suppress
• Cleaned up code related to watershed
  • watershed was one of the candidate packages for using Web Socket in Node.js
  • However, ultimately, we chose ws
  • There are no binary, data, and text event in the ws version of Web Socket
  • Thus, we are removing test code related to these events
• Separating mocks
  • Instead of using an uber FauxSock which mocks Web Socket and TCP/IP Socket, we are opting for a more specific mock for TCP/IP Socket, namely FauxSocket

Testing

Added tests to ensure NodeWebSocket can connect to a real Web Socket server.

[coveralls]

Pull Request Test Coverage Report for Build 4003071240

• 9 of 9 (100.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.003%) to 84.653%

---

Totals
Change from base Build 3841042555:	0.003%
Covered Lines:	20002
Relevant Lines:	22391

---

💛 - Coveralls

[ckkashyap]

I looked at NodeWebSocket.ts in detail and it looks fine.

[tracyboehrer]

@ckkashyap @compulim What is the expected impact of this being a breaking change? What would be a shame is to correct one issue and break another set of customers.

[compulim]

I am modifying the API to become connect(serverAddressOrHostName: string, port = 8082). So it is conceptually backward-compatible.

1. If serverAddressOrHostName is a valid URL (via new URL), then use it as-is, without the second argument (ignore port)
2. Otherwise, serverAddressOrHostName is a host name, then
   • Construct an URL object by using serverAddressOrHostName as hostname and second argument as port
   • The protocol used is ws: and not wss:
   • This is for backward compatibility as previous version suggests non-secure protocol

As we do not have any existing tests that proves the existing code is working, we are doing our best efforts to make it backward compatible.

[compulim]

I tried to write a test to show how previous signature would work. However, there are obvious mistakes in the code that made it very unlikely to work:

• options.headers.upgrade must set to 'websocket'
• Second argument of WebSocket.server.completeUpgrade should be {}, instead of undefined

I am keeping the old code as-is, without any tests.

[ckkashyap]

A warning here may be useful?