chore(networking)!: Remove custom DNS resolution

[ktff]

Closes #2635.

Open questions

• If we don't have intention to have dns configurable and it's fine to not call spawn_blocking through a runtime handle, then we can further remove passing Resolver through contexts and functions, and instead construct Resolver directly at call site. EDIT: We'll keep it as it is.

cc. @lukesteensen

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching Cargo.lock:

• Has at least one other team member approved the dependency changes?

This is an automatically generated QA checklist based on modified files

[ktff]

@Jeffail I'll remove you from review since your file is only slightly changed in tests. But you are welcome to review nevertheless.

[MOZGIII]

it's fine to not call spawn_blocking through a runtime handle

spawn_blocking doesn't take a runtime handle, so it's fine

instead construct Resolver directly at call site

If we want to have it centrally configure - we definitely want it to be passed centrally. However, I'm not sure what our intent is.
To decide rationally - we have to ask ourselves what are the use cases we want to cover here? How would we use custom DNS resolvers?
Personally, and, maybe, not that rationally, I'd prefer to have an infrastructure for using custom DNS resolvers that would allow specifying either the system-configured resolver as the default or, if it's required in a particular case - use a custom resolver. I feel like this approach, regardless of the use cases, is a good balance between flexibility and complexity overhead.

[ktff]

spawn_blocking doesn't take a runtime handle, so it's fine

But it does require the runtime, that's why it must be called from inside of one. The tokio v0.2 that we will transition to eventually does expose a way to make this dependency explicit via a handle.

[lukesteensen]

This is great! Very excited to see this happen.

Even though we've dropped the state, I still think it's fine to keep resolver on the context and access it that way. This means users of the API don't need to care how it's implemented and we can do things like thread an executor automatically.

[ktff]

Noting, do not merge this, we are getting
(signal: 11, SIGSEGV: invalid memory reference)
on MAC

[ktff]

The error started popping elsewhere too so it's not related to this PR.