When creating a QTIP listener with a wildcard port:
- a UDP socket is created first (to reserve the UDP port as XDP will
take it over), and the OS would assign an ephemeral port to it
- a TCP socket is created second (to reserve the TCP port as XDP will
take it over)
- but instead of re-using the same port, the initial config was re-used,
and the OS would assign a different ephemeral port
- this second port would override the first one in the MsQuic socket
config
The main consequences of this bug are:
- the right UDP port was not reserved when creating a listener with a
wildcard port
- if later on, the OS assigned the UDP port matching the listener TCP
port, MsQuic would fail to create a binding (causing the test failure we
observed)
Creating a listener without a port set is largely a test scenario.
Creating a client connection with an unspecified a port was ok because
only a TCP or a UDP socket is created for client connection.
## Testing
C/I. We should add some test to validate port reservation in XDP
scenarios, but it will take efforts to enable test to create sockets
cross-platform.