Spec: clarify RTN15h2

Per slack thread
https://ably-real-time.slack.com/archives/C8SPU4589/p1724257493225679?thread_ts=1724236742.837859&cid=C8SPU4589
, it was not sufficiently clear that the library should be in the
CONNECTING state when it's attempting to reconnect. It must not be in
the CONNECTED state when not actively connected.

Author: SimonWoolf

textile/features.textile

@@ -506,9 +506,11 @@ h3(#realtime-connection). Connection
 * @(RTN15)@ @Connection@ failures once @CONNECTED@:
 ** @(RTN15h)@ If a @DISCONNECTED@ message is received from Ably, then that transport will subsequently be closed by Ably
 *** @(RTN15h1)@ If the @DISCONNECTED@ message contains a token error (@statusCode@ value of 401 and error @code@ value in the range @40140 <= code < 40150@) and the library does not have a means to renew the token, the connection will transition to the @FAILED@ state and the @Connection#errorReason@ will be set
-*** @(RTN15h2)@ If the @DISCONNECTED@ message contains a token error (@statusCode@ value of 401 and error @code@ value in the range @40140 <= code < 40150@) and the library has the means to renew the token, a single attempt to create a new token should be made and a new connection attempt initiated using the new token. If the token creation fails or the next connection attempt fails due to a token error, the connection will transition to the @DISCONNECTED@ state and the @Connection#errorReason@ will be set.
+*** @(RTN15h2)@ If the @DISCONNECTED@ message contains a token error (@statusCode@ value of 401 and error @code@ value in the range @40140 <= code < 40150@) and the library has the means to renew the token, the library must initiate an immediate reconnect attempt, by transitioning to the @CONNECTING@ state, making an attempt to obtain a new token, and initiating an @RTN15b@ resume attempt to the server using that token. If the token creation fails or the next connection attempt fails due to a token error, the connection must transition to the @DISCONNECTED@ state and set the @Connection#errorReason@.
+**** @(RTN15h2i)@ The library MAY briefly transition through the @DISCONNECTED@ state on its way from the @CONNECTED@ to @CONNECTING@. (There is no need for an SDK need to implement this behaviour if it is not already present).
+*** @(RTN15h3)@ If the @DISCONNECTED@ message contains an error other than a token error, the library must initiate an immediate reconnect attempt, by transitioning into the @CONNECTING@ state and initiating an @RTN15b@ resume attempt.
 ** @(RTN15i)@ If an @ERROR@ @ProtocolMessage@ is received, this indicates a fatal error in the connection. The server will close the transport immediately after. The client should transition to the @FAILED@ state triggering all attached channels to transition to the @FAILED@ state as well. Additionally the @Connection#errorReason@ should be set with the error received from Ably
-** @(RTN15a)@ If a @Connection@ transport is disconnected unexpectedly or because a token has expired, then the @Connection@ manager will immediately attempt to reconnect and restore the connection state. Connection state recovery is provided by the Ably service and ensures that whilst the client is disconnected, all events are queued and channel state is retained on the Ably servers. When a new connection is made with the correct connection recovery key, the client is able to catch up by receiving the queued @ProtocolMessages@ from Ably.
+** @(RTN15a)@ If a transport is disconnected unexpectedly (without having received a @DISCONNECTED@ or @ERROR@ protocol message), it should respond as if it had received a non-token @DISCONNECTED@ (following @RTN15h3@).
 ** @(RTN15g)@ Connection state is only maintained server-side for a brief period, given by the @connectionStateTtl@ in the @connectionDetails@, see "CD2f":#CD2f. If a client has been disconnected for longer than the @connectionStateTtl@, it should not attempt to resume. Instead, it should clear the local connection state, and any connection attempts should be made as for a fresh connection
 *** @(RTN15g1)@ This check should be made before each connection attempt. It is generally not sufficient to merely clear the connection state when moving to @SUSPENDED@ state (though that may be done too), since the device may have been sleeping / suspended, in which case it may have been many hours since it was last actually connected, even though, having been in the @CONNECTED@ state when it was put to sleep, it has only moved out of that state very recently (after waking up and noticing it's no longer connected)
 *** @(RTN15g2)@ Another consequence of that is that the measure of whether the client been disconnected for too long (for the purpose of this check) cannot just be whether the client left the @CONNECTED@ state more than @connectionStateTtl@ ago. Instead, it should be whether the difference between the current time and the last activity time is greater than the sum of the @connectionStateTtl@ and the @maxIdleInterval@, where the last activity time is the time of the last known actual sign of activity from Ably per "RTN23a":#RTN23a