fix(dns): rejoin TXT character-strings for EIP-1459 entries over 255 bytes

[MysticRyuujin]

Description

DNS discovery currently resolves zero nodes from every real enrtree, including
all.mainnet.ethdisco.net.

lookup_txt reads only the first <character-string> of a TXT record. RFC 1035 caps a single
<character-string> at 255 bytes, while an enrtree entry is bounded by the 512 byte DNS UDP limit
that EIP-1459 budgets against, and EIP-778 permits a 300 byte ENR, about 404 characters once
base64url encoded. Long entries are therefore normal rather than unusual: go-ethereum deliberately
sizes branch records up to 370 bytes, and 219 of 300 sampled records on the mainnet tree span several
character-strings. hickory returns one list element per character-string, so they have to be rejoined
with no separator, as Go's resolver does (net/lookup.go: "Multiple strings in one TXT record need
to be concatenated without separator").

The loss is total rather than partial because verify_entry_hash from #22582 works correctly: a
truncated record does not hash to its subdomain, so the entry is rejected and its whole subtree is
dropped. Mainnet's first branch record is short enough to survive, but the level-2 branches are 370
bytes, so both subtrees die before any ENR is reached. The failure is only visible as HashMismatch
debug logs, and discv4/discv5 keep supplying peers, which is presumably why it went unnoticed.

Measured against live trees, deduplicating ENRs until the service stayed idle:

tree	before	after	go-ethereum
all.mainnet.ethdisco.net at seq 8393	0	3000	3000
a 25 node tree with multi-string records, second publisher	0	25	25
its 25 node snap subtree	0	25	25

Change

txt_entry concatenates all of txt_data and performs a single UTF-8 decode over the joined bytes.
Decoding per chunk would be wrong in principle, since a multi-byte sequence can straddle a chunk
boundary. No new dependencies.

Tests

• txt_entry_joins_character_strings covers the join directly.
• lookup_txt_reads_record_split_over_character_strings is end to end: a stub UDP nameserver bound
  on 127.0.0.1:0 encodes a real DNS response with hickory_proto, and a resolver built via
  ResolverConfig::from_parts resolves through it, so hickory's actual wire decoder is exercised
  rather than a hand-built TXT value.

Both fail without the change. Reverting txt_entry to txt_data.first() gives:

test resolver::tests::txt_entry_joins_character_strings ... FAILED
test resolver::tests::lookup_txt_reads_record_split_over_character_strings ... FAILED
  left: Some("enrtree-branch:XQ3H...,2M7CLAE7ZKRLNEAFM6ASQUST")
 right: Some("enrtree-branch:XQ3H...,2M7CLAE7ZKRLNEAFM6ASQUSTTU,WLT3...,JXQOS2YKRCDOIKRMGW2X36FJ2U")

The truncation cuts off mid-base32-label at byte 255, which is what makes the record fail its hash
check.

cargo test -p reth-dns-discovery: 22 passed, 1 ignored (the pre-existing live-network test), 2
doctests. cargo +nightly fmt --check and cargo clippy -p reth-dns-discovery --all-targets are
clean.

Before this change the crate could not represent a multi-string record at all. MapResolver stores
one already-joined String per name, so the split is unrepresentable, and the impl on
hickory_resolver::Resolver<P> carrying the bug had no test coverage of any kind. The stub
nameserver added here is the first test infrastructure in the crate that can express it.

Scope

One adjacent issue is out of scope, pre-existing and not made worse by this change: lookup_txt
selects the first TXT record at a name via answers().iter().find_map(...), whereas go-ethereum
iterates every TXT record and takes the first that parses as a known entry. A name serving an
unrelated TXT record ahead of the enrtree entry would still fail. Every public tree apex checked,
all.mainnet.ethdisco.net, all.sepolia.ethdisco.net and all.hoodi.ethdisco.net, serves exactly
one TXT record, so the present impact is nil, and fixing it means either teaching lookup_txt the
enrtree grammar or widening the Resolver trait to return every record, neither of which belongs in
a truncation fix.

[Rjected]

lgtm

[mattsse]

ty