BFD listen addresses could use some love

When configuring a BFD peer, there is a mandatory listener address field that translates to a UdpSocket::bind() call.
If the listener address is set to an unspecified IP (0.0.0.0 or ::), then the bind succeeds as a wildcard address.

However, because there are multiple listeners being bound (one per neighbor), this leaves the opportunity for a wildcard bind to conflict with a more specific bind and the OS returns EADDRINUSE. This can happen if you already have BFD peers configured with a specific listening address, then you try to configure a BFD peer with a wildcard listening address.
e.g.

root@ox:~# mgadm bfd get-peers
Peer       Listen     Required Rx  Detection Threshold  Mode       Status
fd00:1::2  fd00:1::1  300000       3                    SingleHop  Down
fd00:2::2  fd00:2::1  300000       3                    SingleHop  Down
10.0.1.2   10.0.1.1   300000       3                    SingleHop  Down
root@ox:~# mgadm bfd add-peer 10.0.0.2 0.0.0.0 300000 3 single-hop
Error: Error Response: status: 500 Internal Server Error; headers: {"content-type": "application/json", "x-request-id": "9303429a-f452-4d1a-95b2-280527ec613d", "content-length": "124", "date": "Wed, 22 Apr 2026 00:54:44 GMT"}; value: Error { error_code: Some("Internal"), message: "Internal Server Error", request_id: "9303429a-f452-4d1a-95b2-280527ec613d" }
root@ox:~# grep 500 /tmp/mgd.log
{"msg":"request completed","v":0,"name":"slog-rs","level":30,"time":"2026-04-22T00:54:44.882854638Z","hostname":"ox","pid":1615,"uri":"/bfd/peers","method":"PUT","req_id":"9303429a-f452-4d1a-95b2-280527ec613d","remote_addr":"[::1]:62670","local_addr":"[::]:4676","unit":"api_server","module":"admin","component":"mgd","error_message_external":"Internal Server Error","error_message_internal":"Address already in use (os error 125)","latency_us":470,"response_code":500}

One thought on how to avoid this is by having 1 (or 2, if we want to do it per address-family) wildcard listening socket (per BFD port, so a single-hop socket for port 3784 and a multi-hop socket for port 4784) and routing the control packets to the proper FSM... conceptually similar to how we route inbound TCP connections in BGP.

If we don't intend to address this, then a 409 seems like a much more appropriate return code than 500.

Start by tracing BFD peer creation from the mgadm bfd add-peer command through the /bfd/peers API to the UdpSocket::bind() calls. Reproduce the conflict with existing specific listeners and a 0.0.0.0 or :: listener. Done means wildcard and specific listeners are handled without an unexpected 500, or the conflict is reported with a 409 response.