Move outbound sequence number generation to transport layer

[k0nserv]

Currently sequence numbers for outbound RTP packets are created internally inside the track(in the case of TrackLocalStaticSample) and by the user in case of TrackLocalStaticRTP. There are several problems with this:

1. If a track is bound to two different RTCRtpSenders the sequence numbers used by each RTP stream will be the same. This weakens SRTP and makes known-plaintext attacks easier.
2. It breaks RTCRtpSender::replace_track which should allow replacing the current track with a different track with a matching envelope. Since the other track will have its own random starting sequence number this will not work in many instances(the sequence numbers between the two tacks should be consecutive).
3. When pausing one of several RTCRtpSender that a track is attached to the resulting gap in sequence numbers can cause SRTP validation to fail at the remote side(if the sender is paused for long enough). An attempt to address this is made in https://github.com/webrtc-rs/webrtc/pull/316

Suggestion

Move sequence number generation out of the track layer and into transport.

For TrackLocalStaticRTP this might mean that the underlying transport layer overwrites the sequence number of packets passed to write_rtp or perhaps we have a way to signal in TrackLocalStaticRTP whether sequence numbers should be respected or not

[k0nserv]

One problem with this suggestion is that TrackLocalStaticSample has a way to propagate dropped packets via sequence number gaps which would break https://github.com/webrtc-rs/webrtc/blob/5612d59869e1a4b8d991ab129ab27103c2975f5b/webrtc/src/track/track_local/track_local_static_sample.rs#L55-L60

[algesten]

Another part to this is when we implement RTX resend properly. Each RTX channel have separate SSRC and sequence number counter to the one it's repairing. It would seem logical that all sequence number generation is an internal concern and only done just before pushing the packet to the wire.