Healthy connections get destroyed during ice candidate negotiation

Looks like this line here sometimes destroys even healthy connections!

https://github.com/feross/simple-peer/blob/cb73f00eca78054fe57047b2bf12eb2560f25ed3/index.js#L655

It happens when connection temporary fails and ICE is still negotiating candidates.

### A little intro

1) Connection in "failed" state stands for:
> One or more of the ICE transports on the connection is in the "failed" state.
> (https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/connectionState)

But it actually also happen when iceConnectionState is "disconnected".

2) iceConnectionState in "disconnected" state means:
> Checks to ensure that components are still connected failed for at least one component of the RTCPeerConnection. This is a less stringent test than "failed" and may **trigger intermittently** and **resolve just as spontaneously** on less reliable networks, or during temporary disconnections. When the problem resolves, **the connection may return to the "connected" state**.
> (https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/iceConnectionState)

And what I've realized right now, is that actually even "failed" iceConnectionState can be recovered. So may be this line could be also somehow improved as well:
https://github.com/feross/simple-peer/blob/cb73f00eca78054fe57047b2bf12eb2560f25ed3/index.js#L676

### How to reproduce

So I used chrome & safari browsers. And checked connection from 2 macbooks, one connected to 3G another to wifi. I pass signals(offers/answers) manually via messenger

I've used turn& stun servers from Twilio as configuration

Ok. So first I create Peer with `initiator:true, trickle: false,` on first mac. I get offer with candidates.

On another mac then I create Peer with `initiator: false, trickle: false`. And then I pass offer `this.peer.signal(offer)`. If I'll pass answer back to initiator fast enough, connection get created. But I wait for around 15 seconds & then connection get destroyed, because
iceConnectionState switches to "disconnected" or to "failed". And that's what is fishy.
The interesting thing is that if I comment out mentioned lines then I am able to create connection even when it's in "failed" state.

### Thoughts

So this makes me think that "failed" or "disconnected" states for iceCandidates and "failed" state for connection itself don't mean too much. It's not a failure yet, I guess, since it can be reestablished so easily, it's more "on hold" type of state.

I'm not really sure how the issue can be fixed, though since I'm pretty new to WebRTC myself. And all these states are confusing. It needs further experimentation

Thank you!