Use an Arc to share stub resolver

[WhyNotHugo]

This somewhat simplifies usage for call sites. They no longer need to use &&StubResolver for some APIs, and a future can be handed off without being tied to the lifetime of the resolver.

The documentation already mentioned that the StubResolver was behind an Arc so I did not need to updated it. StubResolver now implements clone, which is cheap since it merely clones the Arc with the inner data.

This change is backwards-incompatible, and necessitates a bump in minor for the next unstable release.

Fixes: #175

[WhyNotHugo]

v2: formatting

[partim]

Thank you for the PR!

Would it make sense to offer both, i.e., the current resolver and, say, a SharedResolver that keeps the resolver behind an arc? It would need its own query type, but I suppose that’s fine?

[WhyNotHugo]

Would it make sense to offer both, i.e., the current resolver and, say, a SharedResolver that keeps the resolver behind an arc?

I don't see the value in it.

The difference in performance is meaningless. Each time that a DNS request is executed and parsed, the new implementation creates an Arc instead of a double-reference. Dereferencing the Arc should have no overhead.

The existing API is pretty un-ergonomic to use too, necessitating a double-reference to be used, and it always needs to explicitly outlive queries and their response.

[WhyNotHugo]

Rebased and resolved conflicts.