DTLS should be restarted when the remote DTLS fingerprint has been changed or the tls-id has changed during applying an answer

[mission-liao]

Your environment.

• Version: v3.0.3

What did you do?

• Make a pair of PeerConnections, one is at server side, and another one is at App side.
• The App is crashed or is swipe out from foreground.
• When the App is back, I would need to create a fresh PeerConnection and pair it with the one at server side.
• The pairing is not working, ICE is connected but not the DTLS part
  • The connection-state of PeerConnection at server side shows "connected".
  • The connection-state of PeerConnection at App side turns to "failed".

What did you expect?

• the connection between them should be able to establish

What happened?

• The PeerConnection at server side didn't restart its DTLS handshaking. Per JSEP spec 5.11, PeerConnection should restart DTLS when corresponding parameters changed in remote session-description as offer.

      If the remote DTLS fingerprint has been changed or the tls-id has
      changed, tear down the DTLS connection.  This includes the case
      when the PeerConnection state is "have-remote-pranswer".  If a
      DTLS connection needs to be torn down but the answer does not
      indicate an ICE restart or, in the case of "have-remote-pranswer",
      new ICE credentials, an error MUST be generated.  If an ICE
      restart is performed without a change in tls-id or fingerprint,
      then the same DTLS connection is continued over the new ICE
      channel.  Note that although JSEP requires that answerers change
      the tls-id value if and only if the offerer does, non-JSEP
      answerers are permitted to change the tls-id as long as the offer
      contained an ICE restart.  Thus, JSEP implementations which
      process DTLS data prior to receiving an answer MUST be prepared to
      receive either a ClientHello or data from the previous DTLS
      connection.

We can consider to implement this part in our PeerConnection.SetRemoteDescription.