fix(iroh): Parse DNS answer with multiple records into a proper NodeAddr

[matheus23]

Description

Running iroh-doctor this morning with flub I wasn't able to connect. Flub was on iroh 0.30, I was on iroh main (commit c650ea8).
I noticed this in the logs:

2025-01-08T08:09:59.939435Z DEBUG connect{me=cabd2a9e0b alpn="n0/drderp/1"}:discovery{me=cabd2a9e0b node=1992d53c02}: hickory_proto::error: response: ; header 65474:RESPONSE:RD,RA:NoError:QUERY:3/0/0
; query
;; _iroh.dgjpkxyn3zyrk3zfads5duwdgbqpkwbjxfj4yt7rezidr3fijccy.dns.iroh.link. IN TXT
; answers 3
_iroh.dgjpkxyn3zyrk3zfads5duwdgbqpkwbjxfj4yt7rezidr3fijccy.dns.iroh.link. 30 IN TXT addr=192.168.96.145:60165
_iroh.dgjpkxyn3zyrk3zfads5duwdgbqpkwbjxfj4yt7rezidr3fijccy.dns.iroh.link. 30 IN TXT addr=213.208.157.87:60165
_iroh.dgjpkxyn3zyrk3zfads5duwdgbqpkwbjxfj4yt7rezidr3fijccy.dns.iroh.link. 30 IN TXT relay=https://euw1-1.relay.iroh.network./
; nameservers 0
; additionals 0

2025-01-08T08:09:59.939617Z DEBUG connect{me=cabd2a9e0b alpn="n0/drderp/1"}:discovery{me=cabd2a9e0b node=1992d53c02}: iroh::discovery: discovery: new address found provenance=dns addr=NodeAddr { node_id: PublicKey(1992d53c02cdc04566e5c0edb1ce83305cd550297953a047a445ea3264b54b18), relay_url: None, direct_addresses: {192.168.96.145:60165} }
[...]
2025-01-08T08:10:09.545100Z DEBUG ep{me=cabd2a9e0b}:magicsock:actor:stayin_alive{node=1992d53c02}: iroh::magicsock::node_map::node_state: can not send call-me-maybe, no relay URL

"no relay URL"? Even though the DNS record clearly contains one.

From the logs it showed that the DiscoveryItem didn't contain all information from the DNS answer.

This PR adds a test that initially failed - it only parsed the first TXT record out of the DNS answer, because of a call to records.all, which drained the iterator of all remaining items.

It also fixes this bug by avoiding a call to .all.

Breaking Changes

None.

Notes & open questions

I tried to avoid functional changes besides the bugfix. But, all of this parsing code makes me think of Postel's Law / the robustness principle: Instead of erroring out when we see conflicting information - should we filter out non-matching answer records?
There seems to be some difference between from_pkarr_signed_packet and from_hickory_records: The former is very lenient in what it parses, the latter is very strict and opts to error out when something's amiss.

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3104/docs/iroh/

Last updated: 2025-01-08T15:58:04Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 695a197

[dignifiedquire]

The former is very lenient in what it parses, the latter is very strict and opts to error out when something's amiss.

the reasons is likely, that we "know" what we expect to publish here, but I agree we probably want to be more relaxed here, and just log invalid entries

[matheus23]

This records.all call was the culprit: It takes &mut self, and records is an impl Iterator, so it actually drains all remaining items.

Then below, the empty iterator is .chained with the first item.

[matheus23]

I verified that this fixes the issue connecting between me and flub using iroh-doctor again.