Document how to extend protocol

[ejeffrey]

The current (v2.0) labrad [[Login Protocol]] leaves little room for negotiating protocol version. The login sequence is exactly scripted, and any deviation from it on either side causes the connection to be dropped. The I can see options are:

1. Use magic values for things like the context, message ID, or pw challenge which are technically valid in the old protocol, but never used. New implementations would detect these magic values and react accordingly, while old versions would continue unaware. In principle this works fine, although it could be a bit brittle if an old client accidentally used the magic values and then got confused.

2. Login as the current version, then use a manager setting to "upgrade" to a higher protocol version. This is completely backwards compatible, but probably harder to implement the conversion to the new protocol after login. It also prevents modifying the login protocol itself.

3. Extended the protocol in a non-compatible way by having the client send an unexpected message. Old managers will disconnect, and the new client simply needs to know to reconnect with the old protocol.

I think option 3 is the best. It allows maximum flexibility and future forward compatibility with only requiring slightly more intelligence in the client connect() method of new clients to be backwards compatible, and it doesn't expose us to weird transient bugs related to magic values.

[ejeffrey]

Note: The LabRAD login negotiation does provide a version number field (2), which the client sends to the server after authentication. However, there is no documented way to actually negotiate the protocol. That is, the client and server should choose the highest protocol version they both support.