Spec: fix situations in which presence auto-re-enter needs to happen

[SimonWoolf]

No description provided.

[paddybyers]

Looks good but please see comments

[mattheworiordan]

Thanks.

Before this is merged, please can you:

• Create an issue in all libraries that implement realtime presence to correct this
• Describe what test may be useful to verify the spec change is fixed (making it easier for all client lib devs)
• Update the spec sheet (or rename existing spec items) with these new spec items as I assume, because numbering has been changed, some of these previously implemented spec items may be partially implemented anyway i.e. if we don't do this now in the sheet, later it will be much harder for each client lib developer to understand the spec items are renumbered and moved and quite similar to previous implementations.

[paddybyers]

@SimonWoolf please confirm that the tests that need to exist for this should cover the following.

Construction of these tests will require the use of a mock transport that is capable of sending specific messages to the backend, suppressing the sending of specific messages to the backend, and suppressing the processing of specific messages received from the backend.

Server-sent ATTACHED indicates hasPresence = false but local PresenceMap has members that must be re-entered.

The sequence of events would be:

• connect;
• attach;
• enter a member (via the API), but suppress the ENTER sent by the client to the backend;
• simulate the receipt of that member from the backend, so it is entered by the library into the internal PresenceMap;
• disconnect, and wait for < connectionStateTtl;
• trigger a resume;
• await the CONNECTED and then ATTACHED. The received ATTACHED message should have hasPresence=false;
• verify that the library attempts to re-enter the member;
• verify that the subsequent expected sequence of events occurs (ie the member is entered in the backend, and subsequently reflected back to the client).

Server-sent ATTACHED indicates hasPresence = true followed by SYNC; local PresenceMap has members that must be reentered.

The sequence of events would be:

• connect;
• attach;
• enter a member, memberA, normally;
• enter a member, memberB via the API, but suppress the ENTER sent by the client to the backend;
• simulate the receipt of memberB from the backend, so it is entered by the library into the internal PresenceMap;
• disconnect, and wait for < connectionStateTtl;
• trigger a resume;
• await the CONNECTED and then ATTACHED. The received ATTACHED message should have hasPresence=true;
• await the SYNC;
• verify that the library attempts to re-enter memberB;
• verify that the subsequent expected sequence of events occurs (ie memberB is entered in the backend, and subsequently reflected back to the client).

[SimonWoolf]

please confirm that the tests that need to exist for this should cover the following.

lgtm