chat: add spec points clarifying release behaviour

textile/chat-features.textile

@@ -93,6 +93,8 @@ h4(#rooms-lifecycle-operations). Room Lifecycle Operations
 *** @(CHA-RL1h4)@ @[Testable]@ If the underlying Realtime Channel entered the @FAILED@ state, then the room status will transition to @FAILED@, using the Realtime Channel error as the @cause@ field of the @ErrorInfo@. The same error shall be thrown as the result of the @ATTACH@ operation.
 *** @(CHA-RL1h5)@ @[Testable]@ When the room enters the @FAILED@ status as a result of @CHA-RL1h4@, then the room will detach all channels that are not in the @FAILED@ state.
 *** @(CHA-RL1h6)@ @[Testable]@ When the room enters the @FAILED@ status as a result of @CHA-RL1h4@, and a channel fails to detach on command, then the detach operation will be repeated until such a time that all channels have detached successfully.
+** @(CHA-RL1i)@ Because of the singleton pattern that the core SDKs implement with regards to channels, subsequent instances of a room will use the same underlying realtime channels if the realtime channels are not properly @released@ as part of cleaning up the previous room instance before the new instance is used. Therefore, it is important to ensure that releasing operations (per "@CHA-RC1d@"#CHA-RC1d) have completed before a new room can be attached (to avoid channel objects leaking between instances of rooms).
+*** @(CHA-RL1i1)@ @[Testable]@ If a room instance is in the process of being released and cleaned up (per "@CHA-RC1d@"#CHA-RC1d), then the @ATTACH@ operation of a subsequent instance of the same room shall wait for the release operation of the previous to complete before commencing.
 * @(CHA-RL2)@ A room must be explicitly detached via the @DETACH@ operation.
 ** @(CHA-RL2a)@ @[Testable]@ If the room status is already @DETACHED@, then this operation is a no-op.
 ** @(CHA-RL2b)@ @[Testable]@ If the room is in the @RELEASING@ status, the operation shall be rejected with an @ErrorInfo@ with code @102102@.
@@ -155,9 +157,11 @@ h2(#room-configuration). Room Configuration
 ** @(CHA-RC1a)@ @[Testable]@ Requesting a room from the Chat Client will provide an instance of a room with the provided id.
 ** @(CHA-RC1b)@ @[Testable]@ Once a room has been created on the Chat Client, assuming it is not subsequently released, then the client will return the same room instance on subsequent calls for the same room ID.
 ** @(CHA-RC1c)@ @[Testable]@ If a room is requested with different options to an existing room of the same id, then an @ErrorInfo@ with code @40000@ is thrown.
+** @(CHA-RC1d)@ @[Testable]@ If a room is requested to be released, it is immediately removed from the SDKs room map - meaning subsequent calls to get an instance of a room for the same ID shall produce a new object.
+** @(CHA-RC1e)@ @[Testable]@ Pursuant to @CHA-RC1d@, the room releasing lifecycle operations (see "@CHA-RL3@"#CHA-RL3) shall occur @AFTER@ the room is removed from the room map, but shall complete before the call to release the room completes.
 * @(CHA-RC2)@ Chat rooms are configurable, so as to enable or disable certain features. When requesting a room, options as to which features should be enabled, and the configuration they should take, must be provided.
 ** @(CHA-RC2a)@ @[Testable]@ If a room is requested with invalid configuration, for example: a negative typing timeout, an @ErrorInfo@ with code @40001@ must be thrown.
-** @(CHA-RC2b)@ @[Testable]@ If a room is configured to have a given feature disabled, then attempting to use that feature must result in an @ErrorInfo@ with code @40000@ being thrown. 
+** @(CHA-RC2b)@ @[Testable]@ If a room is configured to have a given feature disabled, then attempting to use that feature must result in an @ErrorInfo@ with code @40000@ being thrown.
 
 h2(#error-codes). Chat-specific Error Codes