[[Receptive]] can get stuck in wrong state when rolling back SDP

[fippo]

tl;dr:
Rollback should bring you back to the pre-offer state, if it's possible at all, both for local and remote offers.
It does not.

While looking at mute @henbos, @alvestrand and me came up with some minor gaps in how receptive is defined. Full story here

1. "process remote tracks" can only make [[Receptive]] false, not true, meaning you can easily get stuck in a non-receptive state:

Full-O/A: sendrecv (receptive=true)
SRD-offer: inactive (receptive=false)
Rollback: sendrecv again but stuck in receptive=false?

2. To only "rollback" the receptiveness in "have-remote-offer" means we don't roll it back in "have-local-offer", so again we get stuck with the wrong receptiveness sate.

[henbos]

The fix we came up with in that CL was to roll back to a receptive state that aligns with the transceiver's currentDirection:

transceiver->internal()->set_receptive(
        transceiver->internal()->current_direction() &&
        RtpTransceiverDirectionHasRecv(
            *transceiver->internal()->current_direction()));

This makes sense, and the fact that rollback isn't applicable in "pr-answer" means we can always trust currentDirection to be whatever state we should be in

[henbos]

Since this is just a bug fix and not a new feature, can we say Ready for PR? @guidou @jan-ivar

[alvestrand]

Agree with ready for PR.
Is it testable? Do we need WPT tests?

[henbos]

Probably good idea to add a WPT test for rolling back and then receiving should unmute track (which it wouldn't do if receptive was stuck)

[fippo]

[[Receptive]] itself isn't testable but we can use mute/unmute as proxy.