Remove minorVersion from handshake response

[mikaelm12]

The master branch needs to be updated with the new information regarding the minorVersion field in the Handshake Response.

Let's remove the minorVersion from the handshake response, since we aren't using it yet (see comments below).

[muratg]

@halter73 can you update this with the current design ideas?

[halter73]

The idea we discussed last week is more-or-less copying the protocol selection logic from SignalR classic which we've had success with in the past.

One of the main goals of our protocol selection logic is to make upgrading the server not break older clients. At the same time, we want to make it possible for newer clients to use new server features not supported by the old clients.

We are not concerned with making newer clients work with older servers. This is because we feel it should generally be easier to upgrade your servers than it is to upgrade every client that may connect to your servers.

In SignalR classic, both the server and the client support a range of protocol versions. Starting out, this range included a single version on both the client and the server.

Over time, the server added support for newer protocol versions while keeping support for older protocol versions in order not to break older clients that may not be upgraded.

Eventually, once the protocol had mostly stabilized, the client also kept support for older protocol versions to support upgrading the client without upgrading the server.

As of today, the SignalR classic server supports protocol versions [1.2,2.0] while the client supports [1.4,2.0].

To make supported protocol ranges work on both the client and server, negotiation works as follows:

1. The client always sends its latest protocol version it supports as part of the negotiate request payload.

   i. Actually, the client sent its latest protocol version as part of the querystring of every requests because it wasn't possible to use state on the server to store this, but that's not longer an issue.

2. The server responds to the negotiate request with a protocol version it supports and configures whatever quirks-mode-like-behavior is necessary.

   i. If the server supports the protocol version sent by the client, use that.
   ii. If the server only supports protocol versions older than that sent by the client, respond with the newest protocol version supported by the server.
   iii. If the server only supports protocol versions newer than that sent by the client, respond with the oldest protocol version supported by the server. This case should always raise an error on the client.

3. Upon seeing the protocol version selected by the server, the client will determine whether it's in the supported range.

   i. If the client supports the selected protocol version, it continues to initialize the connect while perhaps configuring some quirks-mode-like-behavior to support an older protocol version.

   ii. If the client does not support the selected protocol version, fail the connection start with an appropriate exception including the protocol version selected by the server and those supported by the client.

Whether or not we support minor protocol version numbers isn't that important. Ideally, we want to have the protocol version and product version as different as possible so they don't get confused. Having the protocol version not support minor versions could help with that.