Skip the two-second delay when ICETransportPolicy=ICETransportPolicyRelay

[jech]

When looping back through a TURN relay, Chrome takes a few milliseconds to connect: https://github.com/jech/galene/blob/master/static/galene.js#L2307

The equivalent code on the server side takes 2 seconds: https://github.com/jech/galene/blob/master/ice/ice.go#L127

The reason for that is that the TURN delay is fixed to two seconds (ice.defaultRelayAcceptanceMinWait), and this delay is honoured even when ICETransportPolicy is set to relay.

[Sean-Der]

This should be pretty easy to fix!

First I need to confirm if settings aren't properly getting passed here

Then we also need to lower timeouts depending on enabled types here

[jech]

I've added this to the test:

	s.SetHostAcceptanceMinWait(0)
	s.SetSrflxAcceptanceMinWait(0)
	s.SetPrflxAcceptanceMinWait(0)
	s.SetRelayAcceptanceMinWait(0)

and the timing is similar to the browser's.

[AnshulMalik]

Let's say we add 0 wait times for all these, and now we got the relay candidate, so we nominate it and proceed with connection.
And say after a second, we also got a srlfx candidate. So I wanted to know, if we can now choose this instead of the relay one automatically?

[jech]

This issue is about the case when ICETransportPolicy=ICETransportPolicyRelay. There can be no server-refexive candidates in that case, so it's safe to skip the initial delay.

The general case is interesting too, but it's a different issue.

[stv0g]

@jech Maybe fixing this in pion/webrtc is the better place? ICETransportPolicy is a setting from the webrtc module if I am not mistaken?