Revisit `RTL3d` tests.
I think both the purpose and the name of this test are slightly misleading. It claims it tests RTL3d, but instead addresses a bug in its behavior. I didn't find two other RTL3d tests doing a good job in testing this spec. The test aims to check if there is an endless loop for channel state transition after suspended (suspended > attached > suspended), which it does. It shouldn't check if there was a successful connection resume or not. So I've removed this check and renamed the test. Also removed the simulateLostConnectionAndState call, because id and key are reset when the connection goes into suspended state (RTN8c/RTN9c).
Originally posted by maratal in https://github.com/ably/ably-cocoa/pull/1714#discussion_r1405523066
➤ Automation for Jira commented:
The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3963