Local preferences of udp candidates

I'm not sure this was voluntary, but I noticed that all udp host-type candidates where given the same "local preference" value (1) in nice_candidate_ice_local_preference(), due to an implicit fallthrough in a switch/case statement that prevented nice_candidate_ip_local_preference() to be called.

The interesting consequence of using the rank of the interface/ip_address to calculate the priority is that both helper functions that ensured priority and peer-reflexive priority uniqueness can now be dropped. All candidates priorities will be unique per construct (those of type host local, and also those of type server reflexive and of type relay, as their host-local baseaddr is used to compute their priority).

I think the peer-reflexive priority uniqueness helper function (used to defined the priority in stun request) can also be dropped, if we consider the case of the type-relay local candidate as an exception, that doesn't require this priority mangling. And I think it doesn't.

I don't see any bad side effects to that change. Basically for all distinct pairs p1 and p2 of the same component of the conncheck list, the following asserts are true:

+              if (p1->local == p2->local)
+                g_assert (p1->stun_priority == p2->stun_priority);
+              else {
+                g_assert (p1->priority != p2->priority);
+                if (!p1->succeeded_pair && !p2->succeeded_pair)
+                  g_assert (p1->stun_priority != p2->stun_priority);
+                if (p1->succeeded_pair && !p2->succeeded_pair && p1->succeeded_pair->local != p2->local)
+                  g_assert (p1->stun_priority != p2->stun_priority);
+                if (p2->succeeded_pair && !p1->succeeded_pair && p2->succeeded_pair->local != p1->local)
+                  g_assert (p1->stun_priority != p2->stun_priority);
+                if (p2->succeeded_pair && p1->succeeded_pair && p1->succeeded_pair->local != p2->succeeded_pair->local)
+                  g_assert (p1->stun_priority != p2->stun_priority);
+              }

As I write this, maybe the only regression would be the case of a setup with more a single turn relay?