Inactive tracks should not be stopped

[k0nserv]

As showcased in #191 tracks that go from .e.g. sendonly to inactive in the course of applying a remote offer(via set_remote_description) are stopped:

webrtc/src/peer_connection/mod.rs

Lines 1314 to 1316 in de83067

	if direction == RTCRtpTransceiverDirection::Inactive {
	t.stop().await?;
	}

My understanding of the specification is that when a media description becomes inactive that shouldn't cause the corresponding transceiver to stop.

I took a stab at removing this stopping behaviour because it causes the bug in #191 and that works‚ in so far that, it stops the endless loop.

On the JS side reactivating the media description via

transceiver.sender.replaceTrack(newTrack);
transceiver.direction = "sendonly";

and negotiating does not cause webrtc-rs to bring the transceiver back from inactive to recvonly.

[k0nserv]

Instead of stopping here's what I think should happen(based on my reading of the specifications):

Receiving

If we were receiving and now aren't because our local direction will become sendonly or inactive nothing in particular should happen. We'll keep sending RTCP packets for receiver reports and simply receive no data from the peer.

Sending

Similarly, if we were sending and receive an answer that changes our local direction to recvonly or inactive we need to take some action.

RFC8829 has the following to say about applying an answer that changes the direction such that sending is no longer happening.

If the direction attribute in the answer indicates that the
JSEP implementation should not be sending media ("recvonly" for
local answers, "sendonly" for remote answers, or "inactive" for
either type of answer), stop transmitting all RTP media, but
continue sending RTCP, as described in [RFC3264], Section 5.1.

It seems to me like we have an implicit state machine in RTPSender as follows:

Based on the language from RFC8829 it sounds like we'd want to extend this as follows

Any sends on a bound track for a paused RTPSender should either fail or become no-ops. RTCP should continue.

[k0nserv]

This issue duplicates #162, closing it.