Add 'atProtocol' field to client config which clients can send with 'from' verb

[gkc]

Is your feature request related to a problem? Please describe.

Dealing with forwards and backwards compatibility is a core consideration in the platform and the protocol.

Currently we have some feature-guarding in the server which is based on the version of the dart client, which the client currently sends with the from verb - e.g. version 3.0.43, or 3.0.57, or etc. Currently we only use this feature in the server to send error responses as json to clients which we know can comprehend json error responses, and plain strings to other clients. In global_exception_handler.dart:

    if (Version.parse(atConnection.getMetaData().clientVersion) >
        Version(3, 0, 37)) {
      logger.info(
          'Client version supports json encoding.. returning Json encoded error message');
      var errorJsonMap = {
        'errorCode': errorCode,
        'errorDescription': errorDescription
      };
      atConnection.write('error:${jsonEncode(errorJsonMap)}\n$prompt');
      return;
    }

As we will have many different client libraries, we need to make this behaviour work for all platforms.

Describe the solution you'd like

• atServer should comprehend a new field in the clientConfig json called 'atProtocol'
• The value should be set by the client based on what version of the protocol the client understands
• Arbitrarily, I've decided that
  • the current version of the atProtocol as understood by the latest Dart client v3.0.57 is atProtocol version 2.0.0
  • the previous version was 1.5.0
• We should then change the server code snippet above so that clients which state that they are at version 1.5.0 or above, or they are a Dart client at version 3.0.38 or later, will be deemed to understand error responses sent as JSON.

The intention is that, every time we change request or response syntax in the future, we will bump the atProtocol accordingly. There are plenty of other things to consider here and it will evolve in the future but it starts by having the server understand what version of the protocol a client 'understands', and having clients send that information when they issue the from verb

Describe alternatives you've considered

No response

Additional context

No response

[gkc]

Marking for discussion on architecture call before moving to implementation

[gkc]

Discussed - we will go ahead.

Discussed what makes a version change (changes to syntax, new verbs, changed response, etc, anythoing like that) Dsicsused future things like test suites that verify that an atServer or a client library supports version X.Y.Z of the atProtocol