Express RTCPeerConnectionState values using [[IceConnectionState]], and reduce complexity

[jan-ivar]

Fixes #2827.

Since this depends on #2826, a nicer Preview.

---

Preview | Diff

[alvestrand]

This is OK on implementors (easy to code), but hard on users to understand.
Suggest adding an explanatory note about ConnectionState:Connecting, something like:

The state "connecting" means, colloquially, that the connection is not usable at the moment, but it may become usable without any intervention by the user. This refers, for instance, to the state when an ICE connection is in "disconnected" due to a temporary failure, as well as the state when the ICE connection's handshake isn't finished yet.

[jan-ivar]

I added back the technically descriptive note for now.

The state "connecting" means, colloquially, that the connection is not usable at the moment,

I don't think we can say that in general about this aggregate state. E.g. a usable connection may drop to "connecting" if a transport is added, without making the existing connection unusable.

Some of the other language about transient-ness sounded nice, if we can word it differently. Happy to iterate here.

[dontcallmedom-bot]

This issue had an associated resolution in the minutes of WebRTC March 2023 meeting – 21 March 2023 (Issue #2827 / PR #2828: Hard to tell if there are state gaps in connectionState algorithm):

RESOLUTION: PR #2828 can be merged

[dontcallmedom-bot]

This issue was mentioned in WEBRTCWG-2023-02-21 (Page 30)