Screenshare transceiver reused for incoming screenshare without renegotiation

[dbkr]

If you start screensharing in EC and then someone else starts swcreensharing too, you won't see their screenshare. This is because waterfall tries to re-use the transceiver created by the client for the screenshare publish to the SFU for the new screenshare down to the client. Waterfall calls AddTrack and the transceiver is in the recvonly state (from the SFU's PoV) so it's not unreasonable for pion to re-use it, but we'd expect a renegotiation from the SFU to change the direction to sendrecv (the client doesn't get one).

Options to fix:

• Fix whatever bug in pion that means the renegotiation doesn't happen
• Use addTransceiver (presumably pion has this?) to manually add a new transceiver rather than re-use the existing one.

The spec probably isn't super explicit on this, but the second option seems like it would keep things simpler.

[dbkr]

Having checked this in the debugger, actually this isn't quite true - we don't even seem to be calling AddTrack at all for the second screenshare. @EnricoSchw says this looks like pion mixing up the mids of the transceivers.