client: filter mDNS query responses by queried service name

[vleonbonnet]

Summary

The query() method in client.go processes all mDNS response records without validating whether they belong to the service being queried. On networks with many mDNS-enabled devices (smart speakers, streaming devices, etc.), unrelated multicast responses arrive during the query window and are blindly added to the results.

This causes callers like Consul's retry_join (via go-discover) to receive IP addresses of random network devices instead of actual service members, breaking cluster formation.

This resolves the TODO(reddaly) comment at the top of the response processing loop.

Changes

Introduce a validNames map that gates processing of all record types:

• PTR records: only accepted if rr.Hdr.Name matches the queried serviceAddr (case-insensitive). The instance name (rr.Ptr) is added to validNames.
• SRV records: only processed if rr.Hdr.Name is in validNames. The SRV target hostname is also added to validNames so subsequent A/AAAA records for it are accepted.
• TXT, A, AAAA records: only processed if rr.Hdr.Name is in validNames.

Testing

Tested on a home network with ~30 mDNS-enabled devices:

Before (unpatched):

Querying mDNS for _myservice._tcp (10s timeout)...
FOUND: mynode-1._myservice._tcp.local. 10.0.1.10:8301 ([])
FOUND: mynode-2._myservice._tcp.local. 10.0.2.10:8301 ([])
FOUND: device-A._spotify-connect._tcp.local. 10.0.1.50:35552 ([CPath=/zc/0 VERSION=1.0 Stack=SP])
FOUND: device-B._sleep-proxy._udp.local. 10.0.1.51:53482 ([])
FOUND: device-C._spotify-connect._tcp.local. 10.0.2.50:55853 ([CPath=/zc/0 VERSION=1.0 Stack=SP])
FOUND: device-D._googlecast._tcp.local. 10.0.2.51:1400 ([])

After (patched):

Querying mDNS for _myservice._tcp (10s timeout)...
FOUND: mynode-1._myservice._tcp.local. 10.0.1.10:8301 ([])
FOUND: mynode-2._myservice._tcp.local. 10.0.2.10:8301 ([])

Fixes #96

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}