Providing the address to bind isn't always possible, since it is not
known in advance which of the device's addresses are reachable by a IGD.

Since we can only map one port to the address we need to pick which port
to map carefully.

The dominant constraint is that routers may reject mapping requests
where the address to map doesn't match the sender's address,
and by using the address the device was discovered on we guarantee that
the address matches some address the Control Point sends requests from
so when the Router sends the PortMappingAdd action from every bound UDP
port it guarantees that the router will accept one of them if

The second constraint is that some addresses are faster than others
e.g. Ethernet is usually preferred over WiFi.
Linux handles this preference with metrics in the routing table
and could be consulted by connecting a socket to the gateway
and getting the local address of the socket.

However this address may not be one of the addresses the Control Point
is serving or the computer may be connected to multiple networks with
the same gateway address and the heuristic can't return both addresses
so the fastest responding request will have to suffice.

Signed-off-by: Richard Maw <[email protected]>

It is useful to be able to hook into the logic to provide user feedback
on whether any IGDs were successfully discovered or successfully mapped
ports e.g. via a CompletableFuture that you can get with a timeout.

Signed-off-by: Richard Maw <[email protected]>

InternetGatewayDevice:2 adds WANConnectionDevice:2 as a sub-device
that implements WANIPConnection:2 instead of WANIPConnection:1.

This provides the same methods as WANIPConnection:1 but has some
additional constraints such as the gateway must only serve it on the
LAN interface and should reject mappings to an address that wasn't the
origin of the request.

Signed-off-by: Richard Maw <[email protected]>