Implement /dns and /resolve

[ljedrz]

Add a rudimentary implementation of the /dns and /resolve endpoints; putting it out there already, as due to the similarity of these two endpoints I'm not 100% sure how much we want to "condense" their inner workings.

This upgrades or conformance suite stats from

170 passing
50 pending

to

178 passing
42 pending

[ljedrz]

note: this one gave me a bit of a headache - the compiler was pointing to a very long issue with the HTTP warp call, but this was actually the root cause of the problem

[koivunej]

Yeah I wonder if the future should be just written open as async fn to be simpler in every way, but haven't tried this myself ... for a while at least. Though, there's nothing obvious causing this, perhaps the path inside domain-resolve is just so long.

[ljedrz]

seems that I've missed a test - I'll leave this one here as a draft and tinker with it some more

[ljedrz]

the curious thing is that only the /dns tests fail on Windows, while the /resolve ones pass, even though they both use the same internal machinery 🤔; why does Windows not resolve ipfs.io?

[aphelionz]

bors r+

[ljedrz]

in the end the issue was that the domain_resolv crate just doesn't read the DNS configuration in Windows; the docs for ResolvConf::default (which is used by the StubResolver) state:

XXX This currently only works for Unix-y systems.

the solution was to use the ipconfig crate in order to read the DNS configuration in Windows and to provide that information to the StubResolver manually.

[ljedrz]

Cc #6

[ljedrz]

bors r-

[bors]

Canceled.

[ljedrz]

bors r+

[bors]

Build succeeded:

• ci