add Abort function to sctptransport

[craymond12]

Description

the association should send the abort message before before changing the state to closed and closing the association as defined by the webrtc spec in step 6
https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-close

When the peerConnection is closed without sending an abort message, it cause the other peer to hang on it's connection until it face a timeout or other kind of event showing that the connection is closed
This can be an issue with device who can only do a few concurrent stream

This was tested with real cameras and instead of the connection hanging for 30 seconds, it closed immediately

[sukunrt]

This change is correct, but we probably also need to ensure that we don't send the DTLS Close Alert on connection close. We do that currently.

This is an annoying aspect of the spec. The way to detect peer connection close is by opening a datachannel that will be closed on close of the peer connection. See here:
w3c/webrtc-pc#1799 (comment)

If you're not using it from the browser, you can use the OnClose callback on the SCTPTransport

webrtc/sctptransport.go

Line 303 in 179397b

func (r *SCTPTransport) onClose(err error) {

event to detect connection close.

[craymond12]

This change is correct, but we probably also need to ensure that we don't send the DTLS Close Alert on connection close. We do that currently.

This is an annoying aspect of the spec. The way to detect peer connection close is by opening a datachannel that will be closed on close of the peer connection. See here: w3c/webrtc-pc#1799 (comment)

If you're not using it from the browser, you can use the OnClose callback on the SCTPTransport

webrtc/sctptransport.go

Line 303 in 179397b

func (r *SCTPTransport) onClose(err error) {

event to detect connection close.

If I understand correctly, we should replace the close Notify by the abort message
On my tests with real devices, I had pion on the consumer side and an unknown implementation of webrtc on the producer side

It is kind of a big behavior change, on how the peerConnection notify the other party of the close but abort should be the way to go as it is the standard and we can expect this behavior everywhere else

Currently the Close of the conn.go in Dtls always send the bool byUser to true to the private close
Should I simply remove the byUser param and the following code:

if c.isHandshakeCompletedSuccessfully() && byUser {
		// Discard error from notify() to return non-error on the first user call of Close()
		// even if the underlying connection is already closed.
		_ = c.notify(context.Background(), alert.Warning, alert.CloseNotify)
	}

or give access to the bool in the public Close and rename it for notifyClose instead of byUser
And lastly, should I merge this PR, then modify the Dtls lib, then do a second pr in webrtc to update the dtls version?
Or just update the Dtls in this PR?

I did not have any issue by having both the abort and notifyClose in my tests