Add the core functionality required to resolve Human Readable Names

[TheBlueMatt]

This adds new onion messages and a new onion message handler for bLIP 32 messages. It also adds a utility which verifies the proofs and turns them into URIs or Offers. I have a followup ready which wires it all up in ChannelManager as well as a message handler that does the resolver end of bLIP 32, but the latter is blocked on #3178 and I kinda want to land them at the same time so we have some tests. Sadly this PR also adds some code that's not really testable without that, but its pretty straightforward.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 20.52980% with 120 lines in your changes missing coverage. Please review.

Project coverage is 89.55%. Comparing base (a661c92) to head (9335c9b). Report is 35 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/onion_message/dns_resolution.rs	8.33%	77 Missing :warning:
lightning/src/onion_message/messenger.rs	36.00%	15 Missing and 1 partial :warning:
lightning/src/onion_message/packet.rs	0.00%	8 Missing and 1 partial :warning:
lightning/src/ln/peer_handler.rs	0.00%	6 Missing :warning:
lightning/src/onion_message/functional_tests.rs	45.45%	6 Missing :warning:
lightning/src/ln/offers_tests.rs	0.00%	3 Missing :warning:
lightning/src/util/ser.rs	72.72%	3 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3179      +/-   ##
==========================================
- Coverage   89.68%   89.55%   -0.13%     
==========================================
  Files         126      127       +1     
  Lines      103168   103300     +132     
  Branches   103168   103300     +132     
==========================================
- Hits        92522    92511      -11     
- Misses       7934     8070     +136     
- Partials     2712     2719       +7     

Flag	Coverage Δ
	89.55% <20.52%> (-0.13%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[tnull]

This adds new onion messages and a new onion message handler for bLIP 32 messages. It also adds a utility which verifies the proofs and turns them into URIs or Offers. I have a followup ready which wires it all up in ChannelManager as well as a message handler that does the resolver end of bLIP 32, but the latter is blocked on #3178 and I kinda want to land them at the same time so we have some tests. Sadly this PR also adds some code that's not really testable without that, but its pretty straightforward.

I'd love to pickup review on the series. Mind opening a tracking issue for the series of PRs that would allow to keep track where we're at, on what which parts are blocked, and which PRs we (reviewers) can still expect to be opened, etc.?

[TheBlueMatt]

While BIP353 will (hopefully) be an integral part of Lightning payments soon, it still seems all the DNS stuff is more a utility. I'm wondering if in terms of code organization it would be beneficial to have this live as part of an lightning-dns-resolution crate or similar?

I wanted to do this, but it creates a circular reference. That crazy has to depend on lightning for some of the onion message types, and then we want lightning to depend on it for ChannelManager to be able to directly send to BIP 353 names :/

The stuff that is here is the API that folks will have to use if they want to do DNSSEC resolution over onion messages and resolve to a bitcoin: URI, but I have a branch that does the full integration at https://git.bitcoin.ninja/index.cgi?p=rust-lightning;a=shortlog;h=refs/heads/2024-07-human-readable-names-resolution for offers resolution specifically.

[TheBlueMatt]

I'd love to pickup review on the series. Mind opening a tracking issue for the series of PRs that would allow to keep track where we're at, on what which parts are blocked, and which PRs we (reviewers) can still expect to be opened, etc.?

I mean I can, but its only two PRs, at least after the above issue. The full branch I considered making one big PR, but it seemed like it could go in two. The second is linked above.

[TheBlueMatt]

Rebased.

[arik-so]

With the lightning-types crate, would the circular reference still be an issue?

[TheBlueMatt]

Yea, its a separate issue. In theory we could move the BIP 353 Onion Message Handler trait out to lightning-types (or some new crate) which lightning then depends on to implement it in OnionMessenger and ChannelManager and then we keep the current separate server-side crate with the dns resolver, but I'm not sure its worth it for the one trait.

[TheBlueMatt]

Going forward, will the client and the resolver always be modal, or can we think of a scenario where both need to be active at the same time (i.e., allowing to resolve locally for others, but also to query other nodes)?

Yea, I anticipate this will definitely happen sometimes. Certainly ldk-sample/"simple" LDK routing nodes will want to support both. I'll update the server-side logic to optionally act as a wrapper.

Rebased and squashed down all the fixups, also addressing the minor comments from @tnull above.