A Proposal for aggregate PeerConnection.dtlsstate

I've been thinking more about https://github.com/w3c/webrtc-pc/issues/278 :
How does the JS know that something is wrong with DTLS, but not ICE?  And
I've come to the conclusion that the problem isn't error reporting.  The
problem is that our PeerConnection "aggregate state" is lacking.
Right now, PeerConnection has two aggregate state across all IceTransports:
 PeerConnection.iceconnectonstate and PeerConnection.icegatheringstate.
But is has no aggregate state across all DtlsTransports.   This means that
applications that listen to PeerConnection.iceconnectionstate to know if
the peers are connected will

1.  Think things are fully connected before they fully are (by at least 2
RTTs).  No media can flow until DTLS is connected.
2.  Thnk things are fully connected even when they are not, in the case
that DTLS fails to connect but ICE is connected.


To fix this, I propose we add one more aggregate state:

partial interface PeerConnection {
  readonly attribute DtlsTransportState dtlsState;
  attribute EventHandler ondtlsstatechange;
}

Where the state is aggregated as follows:
1.  if any of the DtlsTransports are in the failed state => failed
2.  else if any of the DtlsTransports are in the connecting state =>
connecting
3.  else if all of the DtlsTransports are in the new state or closed state
=> new
4.  else if all of the DtlsTransports are in the connected state or closed
state => connected
5.  else => connecting (mix of new and connected)


Applications can use it like they are currently are use iceConnectionState,
except now they will have a more accurate idea of if things a "fully"
connected:

pc.ondtlsstatechange = function() {
  if (pc.dtlsstate == "failed") {
    // Uh-oh!
  } else if (pc.dtlsstate == "connected") {
    // Great!
  } else {
    // meh
  }
}



For more detail, I have created PR 291 (
https://github.com/w3c/webrtc-pc/pull/291).