What should happen to the ICE gathering state when iceTransports is changed?

Consider the scenario where .iceTransports is set to 'relay', and so relay
gathering occurs first; non-relay gathering only occurs after
.iceTransports is changed to 'all'. This is the scenario where a callee
wants to avoid disclosing their location (real ip address) until accepting
the call.
The flow goes something like:new PC({iceTransports:
'relay'})setRD(offer)createAnswersetLD(answer)onicegatheringstatechange(gathering)onicecandidate(relay1)onicecandidate(relay2)A:
setConfiguration({iceTransports:
'all'})onicecandidate(null)onicegatheringstatechange(complete)B:
setConfiguration({iceTransports: 'all'})
In case A, we could definitely release the gathered ICE candidates
immediately, with no issues. But in case B, does it make sense to emit
them, since gathering has completed?
Options:1) Emit them. No state change occurs. You called this API, you deal
with it. (Simple, but may cause issues, especially if onicecandidate(null)
has triggered an end-of-candidates signal to the remote side.)2) Transition
back to gathering, emit the candidates (which will happen immediately,
necessarily), go back to complete. (Changes the meaning of a
"complete"->"gathering" transition, which previously only occurred on a new
m= line being added, or an ICE restart. May have the same issues as above,
with end-of-candidates)3) No candidates are emitted, no state change
occurs. The new type of candidates is gathered on the next ICE restart.
(Complicates the use case above; remote side would need to re-offer with
ice restart after accepting the call. But no signaling issues, and allows
changing iceTransports to a more restrictive type.)