Stealth: RESOLVER

[cookiengineer]

The old DNS Connection implementation had a centralized and easy-to-use DNS.resolve() method that was used by the Hosts Service. The new generic DNS transport implementations (that also focus on Multicast Compatibility) have no support for a generic resolve() method, and therefore this method needs to be implemented in a different DNS Ronin interface.

The stealth.server.RESOLVER should implement the old resolve() method and offer a centralized, easy-to-use API that abstracts away all the ronin's capabilities. As this DNS Ronin implementation should be a cross-protocol AND cross-server DNS ronin, it will maintain a list of known-to-work DNS servers that have either support for DNS via HTTPS, DNS via TLS, and then fallback to DNS via UDP only in the absolute worst case.

• [x] Integrate SERVERS list from old DNS implementation
• [x] Offer a RESOLVER.resolve() API
• [x] Integrate DNSS Connection
• [x] Integrate DNSHTTPS Connection
• [x] Integrate DNS Connection
• [x] Implement a rotating Ronin that spreads out DNS requests unpredictably (in a resorted-on-use manner).

[cookiengineer]

The prototype of the new RESOLVER API has been implemented.

Once implementations for the DNSviaHTTPS and MDNS Connection are ready, it should transparently be able to resolve both local and global peers and domains.

Once Radar is online, user-specific domains (for their TLS certificates) have to be resolved via radar's API. But that's currently unclear as the API for radar hasn't been specified yet in that regard.

IPv6 support also got included, so if a local IPv6 is available (with a non-local link scope), it is assumed the network supports IPv6 and therefore Multicast DNS broadcasts are also done to ff02::fb to discover local peers.