[mDNS]: Queries first sent to IPv6 when `socket-mdns` is enabled even if link is down

[AnthonyGrondin]

Description

The current mDNS implmentation has an issue where requests will first be sent to IPv6 multicast, even if the IPv6 link isn't configured.

This is an issue I finally found after enabling / disabling the proto-ipv6 feature.

This section is the culprit:

smoltcp/src/socket/dns.rs

Lines 542 to 554 in a54589c

	// As per RFC 6762 any DNS query ending in .local. MUST be sent as mdns
	// so we internally overwrite the servers for any of those queries
	// in this function.
	let servers = match pq.mdns {
	#[cfg(feature = "socket-mdns")]
	MulticastDns::Enabled => &[
	#[cfg(feature = "proto-ipv6")]
	MDNS_IPV6_ADDR,
	#[cfg(feature = "proto-ipv4")]
	MDNS_IPV4_ADDR,
	],
	MulticastDns::Disabled => self.servers.as_slice(),
	};

When doing a normal DNS request or doing an mDNS request with socket-mdns disabled, it uses the provided servers from DHCP:

self.servers.as_slice()

When doing an mDNS request with socket-mdns enabled, it uses the following:

MulticastDns::Enabled => &[ 
    #[cfg(feature = "proto-ipv6")] 
    MDNS_IPV6_ADDR, 
    #[cfg(feature = "proto-ipv4")] 
    MDNS_IPV4_ADDR, 
]

Which will force the use of the IPv6 multicast address before IPv4, even if the link isn't configured.
This is the issue because then the request will wait for 10 seconds until it tries with the IPv4 address, as we can see in the following logs:

TRACE (3501) - Starting a mDNS query
TRACE (3502) - sending 34 octets to ff02::fb from port 8759
TRACE (3814) - Rejecting IPv4 packet; any_ip=false
TRACE (4502) - sending 34 octets to ff02::fb from port 8759
TRACE (4531) - Rejecting IPv6 packet; any_ip=false
TRACE (6502) - sending 34 octets to ff02::fb from port 8759
TRACE (7876) - Rejecting IPv4 packet; any_ip=false
TRACE (10237) - Rejecting IPv6 packet; any_ip=false
TRACE (10502) - sending 34 octets to ff02::fb from port 8759
TRACE (10880) - Rejecting IPv4 packet; any_ip=false
TRACE (11037) - Rejecting IPv6 packet; any_ip=false
TRACE (12047) - Rejecting IPv6 packet; any_ip=false
TRACE (13442) - Rejecting IPv4 packet; any_ip=false
TRACE (13674) - sending 34 octets to 224.0.0.251 from port 8759
TRACE (13699) - receiving 50 octets from Ipv4(192.168.32.135):8759
TRACE (13700) - A: 192.168.32.135

Expected behaviour

It should be inferred from the state of the IPv4 and IPv6 links which address to use, when both protocol features are enabled. Else, anyone sending a request without having an IPv6 link configured will have to wait a very long timeout. When having an IPv6 link configured and an IPv4 link not configured, this isn't an issue because it will use the IPv6 multicast address first.