Address concurrency-related issues not addressed by feature spec

[lawrence-forooghian]

Split from #28.

There are places where the feature spec seems to be written with a single-threaded environment in mind. This means things like:

• assuming that after a certain channel operation completes, an immediate fetch of the channel’s state or errorReason will return something from a known proper subset of possible values
• assuming that a fetch of the channel’s properties.channelSerial reflects the current state of the channel (I can't speak about this one in detail because I haven't worked on it, but it came up in discussions of Implement sending and receiving chat messages #24)
• assuming that upon receiving a channel state change, the channel’s state is equal to the state change’s current
• assuming that if you fetch a channel’s state and then its errorReason, they will both refer to the same channel state
• assuming that if you check a channel’s state, and it’s $x$, and you then immediately add a state listener, you’ll definitely find out if the channel changes to a state other than $x$

We need to decide what to do about this.

Update: further things noticed in code:

• what are consequences of using channel.properties in threaded environment?
• or checking channel.state for CHA-M5a

┆Issue is synchronized with this Jira Task by Unito