diago: client sources UDP from a configured port even when nothing listens on it

[Mliviu79]

For UDP transports, createClient passes tran.BindPort into sipgo.WithClientConnectionAddr whenever it has a resolved hostname, without checking whether anything is listening on that port.

Sourcing from a listened port reuses that connection. Sourcing from any other port is a fresh bind, which the OS refuses as soon as another process owns the port.

That distinction matters because a UA may register before it serves. At that moment nothing holds the configured port, so pinning it there turns an unrelated process on the same port into "bind: address already in use" on the REGISTER, rather than the intended connection reuse.

Fix: return the requested port only when the transport layer already lists it in ListenPorts("udp"), and 0 otherwise, which asks for an ephemeral port and always binds. The check is for that specific port rather than for any listener at all — serving 5060 says nothing about whether 25000 is bindable.

[Mliviu79]

Closing this too, because the "Fix:" paragraph above prescribes an approach that does not work, and I would rather not leave that standing as a description of the problem.

Checking ListenPorts("udp") cannot qualify the pin at the point where the decision is made: createClient runs inside the ListenReadyCtxKey callback, which fires before the transport layer registers the connection, so the lookup always misses and the pin is dropped unconditionally rather than conditionally. Detail and measurements in #157.

The bug the first four paragraphs describe is real and unchanged — sourcing from a port nothing listens on is a fresh bind, and it collides with whatever owns that port. I will refile it with a correct fix.

[Mliviu79]

Reopening — closing this was wrong. The bug described in the first four paragraphs is real and unfixed, and I removed a valid report over a defect in the last one.

The correction is to the prescribed fix. Checking ListenPorts("udp") cannot qualify the pin, because listenReadyCtx fires before ServeUDP registers the connection — the lookup is empty at the point the decision is made, so it always resolves to "do not pin". That is a workable outcome but it is not the conditional the paragraph claims.

The defect itself is unchanged: createClient passes tran.BindPort into WithClientConnectionAddr without anything holding that port, the pool lookup misses, and CreateConnection binds a second socket on the same local address. Whichever side binds first wins — when the client wins, the later Serve fails with bind: address already in use and SIP never comes up.

#157 carries the change, with a corrected description and the corrected test.