candidate: ensuring stun priority uniqueness no more needed

candidate: ensuring stun priority uniqueness no more needed

The uniqueness of candidate priorities is achieved by the iteration on
the ip local addresses for local host candidates, and also on their base
address for reflexive and relay candidates. Helper function checking
its uniqueness at allocation time is not required anyore.

The priority of the stun request (prflx_priority) is built from the
priority of the local candidate of the pair, according the RFC 5245,
section 7.1.2.1. This priority must be identical to a virtual "local
candidate of type peer-reflexive that would be learned as a consequence
of a check from this local candidate."

Outgoing stun requests will come from local candidates of type host or
type relayed. The priority uniqueness of local candidates of type host
implies the uniqueness of the computed peer-reflexive priority.  And
relay local candidates cannot produce a peer-reflexive local candidate
by design, so we can safely use their unique local priority too in
the stun request.