Avoid RTX payload type collisions in 1.x (see #3078)

[lminiero]

This PR aims at providing the same fix @tmatth provided in #3078 for 0.x, that is the fact Janus might generate payload types for RTX that conflict with existing payload types: the reason for this issue was that we only had checks for avoiding conflicts within the context of a specific m-line, without taking into account payload types used in other m-lines though. This patch tries to address that by adding additional maps to the PeerConnection object in the Janus core too, that are updated every time a (re)negotiation takes place to keep track of payload type allocations and mappings with RTX one, when needed.

It seems to be working fine in the few tests I made, and specifically with the mountpoint configuration @tmatth could replicate the problem with, but of course I haven't tested this extensively. As such, please do and provide feedback, so that we can catch potential regressions before we merge this.

[tmatth]

This looks good my testcase at least (rtx is now using payload type 98, vs. payload type 97 for opus and 96 for vp8):

tmatth@bellini:/big-repos/example-webrtc-applications/janus-gateway/streaming$ go run main.go 
GOT JSEP: 
v=0
o=- 1664367867708188 1 IN IP4 192.168.0.91
s=Mountpoint 1
t=0 0
a=group:BUNDLE audio video
a=extmap-allow-mixed
a=msid-semantic: WMS janus
m=audio 9 UDP/TLS/RTP/SAVPF 97
c=IN IP4 192.168.0.91
a=sendonly
a=mid:audio
a=rtcp-mux
a=ice-ufrag:1Eir
a=ice-pwd:Rr+UiGQeS8ImfzPe1hAXr9
a=ice-options:trickle
a=fingerprint:sha-256 49:67:B1:03:3A:A5:CF:DC:65:85:04:E4:72:53:E2:16:22:7B:46:94:48:99:52:18:DD:4B:8E:57:14:C1:8E:32
a=setup:actpass
a=rtpmap:97 opus/48000/2
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=msid:janus janusa0
a=ssrc:610456597 cname:janus
a=ssrc:610456597 msid:janus janusa0
a=ssrc:610456597 mslabel:janus
a=ssrc:610456597 label:janusa0
a=candidate:1 1 udp 2015363327 192.168.0.91 58895 typ host
a=candidate:2 1 udp 2015364351 172.17.0.1 56026 typ host
a=candidate:3 1 udp 2015363583 10.42.0.0 50978 typ host
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 96 98
c=IN IP4 192.168.0.91
a=sendonly
a=mid:video
a=rtcp-mux
a=ice-ufrag:1Eir
a=ice-pwd:Rr+UiGQeS8ImfzPe1hAXr9
a=ice-options:trickle
a=fingerprint:sha-256 49:67:B1:03:3A:A5:CF:DC:65:85:04:E4:72:53:E2:16:22:7B:46:94:48:99:52:18:DD:4B:8E:57:14:C1:8E:32
a=setup:actpass
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:98 rtx/90000
a=fmtp:98 apt=96
a=ssrc-group:FID 2688423809 44961990
a=msid:janus janusv0
a=ssrc:2688423809 cname:janus
a=ssrc:2688423809 msid:janus janusv0
a=ssrc:2688423809 mslabel:janus
a=ssrc:2688423809 label:janusv0
a=ssrc:44961990 cname:janus
a=ssrc:44961990 msid:janus janusv0
a=ssrc:44961990 mslabel:janus
a=ssrc:44961990 label:janusv0
a=candidate:1 1 udp 2015363327 192.168.0.91 58895 typ host
a=candidate:2 1 udp 2015364351 172.17.0.1 56026 typ host
a=candidate:3 1 udp 2015363583 10.42.0.0 50978 typ host
a=end-of-candidates

Connection State has changed checking 
Connection State has changed connected 
EventMsg map[result:map[status:started] streaming:event]WebRTCUp type 7683146238909134

Got VP8 track, saving to disk as output.ivf
Got Opus track, saving to disk as output.ogg

[lminiero]

Thanks for double checking! Yep, I tried the exact same mountpoint you shared in your PR, with opus=97 and vp8=96, to make sure 97 wouldn't be used for rtx as well as it did before. I tried the EchoTest too, to test a situation where payload types are originated by the browser, and it seemed fine there as well. I'll have to make some tests with renegotiations, as that may uncover some things we may have to address. In case you manage to also make some other tests yourself, please do keep me posted.

[lminiero]

Merging.