conduit-mirage: update to dns-client 8.0.0 API changes

[hannesm]

No description provided.

[hannesm]

The actual questions are, for whomever uses conduit: should the dns client be an input to conduit (and thus allowing it to be reused across a unikernel)? And one step further, should the happy-eyeballs as well be an input to the conduit?

I do not understand the design of conduit, and try hard to not use conduit in my unikernels. This is a community service to adapt conduit to the breaking API change in dns-client. I'd appreciate your input here @mirage/core -- esp. for those who're interested in using conduit.

[samoht]

The intended high-level goal of conduit is to resolve a domain-name into an endpoint and then to connect or listen/accept on such endpoints to get (mirage) flows. I guess happy-eyeballs is helping with the first part?

[hannesm]

Happy eyeballs - as defined by IETF in https://datatracker.ietf.org/doc/html/rfc8305 - purpose is to connect via any Internet protocol to a remote host and port. In addition our happy-eyeballs exposes a lower interface to allow connecting to a set of ip addresses and ports (useful e.g. if you've a set of DNS resolvers, where reaching one is sufficient).

I think I do not know which users of conduit that use the resolution and connecting to an endpoint are around -- maybe cohttp-client?

For me, from a higher level view, it should be sufficient to have a single happy-eyeballs and a single DNS client in one unikernel, so I don't quite understand why conduit should create their own (instead of getting this passed in) -- the benefits include a shared DNS cache, fewer Lwt tasks, ...

Stepping back a bit, what is the benefit of conduit (in the resolution case) over happy-eyeballs (which internet protocols does conduit support? does it behave like happy-eyeballs in connecting in parallel and using the first successfully established connection, giving slight preference to IPv6)? I understand it used to (or still does) support xen vchan, but is that used by anybody? Would it be beneficial to remove the resolver part from conduit and just use happy eyeballs? As mentioned earlier, I don't quite know which applications / libraries are using this part of conduit. Any insight would be valuable.

[hannesm]

I will merge and release this PR. It is only to move forward with mirage & dns (esp. in the mirage-skeleton CI). Still the questions about actual users of "conduit" is open, and also how the happy-eyeballs and dns-client should be integrated. But since I don't (at least directly, I guess only in caldav via webmachine & cohttp) use conduit, and I struggle with its code, I won't propose anything in that direction. The good news is this works.