Initial attempt on delta related changes specification

[codemerx]

Attempts to specify the changes to the client library introduced by the deltas feature. There would include deltas, channel params, bits of rewind, etc.

This PR is based on the discussions and materials at https://github.com/ably/wiki/pull/391 and https://github.com/ably/wiki/issues/380.

[SimonWoolf]

I think perhaps we haven't been clear enough about the purpose of the features spec -- our fault, apologies. This PR seems to be treating it as something like a raw form of our user documentation, but it isn't that. Rather it's a list of client library features with specifications for each one, that a client library developer can go through and implement. (We have a spreadsheet where we track which items are implemented by which client library). Conformance to a version of the spec item is how we determine if a client library is ready to be released with a particular version number.

[SimonWoolf]

Looking much better 🙂

Still to do: specify the messageId bookkeeping (extras.delta.from !== this._lastPayload.messageId etc)

[mattheworiordan]

Various comments. One issue I have is that this PR is not based against the 1.2 WIP spec, so when I try and reference spec items such as RTL4c, which I would assume cover off how ChannelOptions are sent to Ably (it does exist, but covered un RTL4j now in #766), it is out of date, and such this PR cannot really be reviewed in full. Why was it not based against #766 (branch channel-params).

Also, as a general note:

• Please remember to use @ symbols to surround code symbols such as ATTACH or ProtocolMessage
• I think we can do better at helping developers who read this spec to understand not just what is required, but also to help test it. We are looking for consistency across our client libraries not just in the assumed code and behaviours, but also in out tests.

[marto83]

I’m looking at the spec items about delta recovery. The spec makes it clear about what I need to do in the happy path where the recovery succeeds. However it doesn't cover what happens if the recovery fails.
Let’s stay we start a recovery and send a new ATTACH message but that times out - the default behaviour will kick in and the channel will become SUSPENDED. What happens when we re-attach it (no matter who triggered that). Are we still in recovery mode and send the serial of the last message? Or do we forget about it and you just get attach from that moment on.

[codemerx]

I’m looking at the spec items about delta recovery. The spec makes it clear about what I need to do in the happy path where the recovery succeeds. However it doesn't cover what happens if the recovery fails.
Let’s stay we start a recovery and send a new ATTACH message but that times out - the default behaviour will kick in and the channel will become SUSPENDED. What happens when we re-attach it (no matter who triggered that). Are we still in recovery mode and send the serial of the last message? Or do we forget about it and you just get attach from that moment on.

We do not specify recovery mode for the channel. We specify recovery actions that should be taken. If the ATTACH never results in ATTACHED reply then one just follows the spec, i.e. the channel becomes SUSPENDED and so on. Whatever happens to it later on should not depend on the failed delta decoding recovery attempt.

[paddybyers]

A few minor comments but otherwise I think this is ready to merge.