Disable cache by default for DNS ServiceDiscoverer

[idelpivnitskiy]

Motivation:

When we poll DNS in the background the cache is not important because we always schedule the next query after cache expires. It only helps with concurrent resolutions of the same address, which in practice should be minimal if users properly reuse clients. The disadvantage of having a cache is that if it gets poisoned with invalid or stale entries there is no way to clear the cache. Cancelling the events publisher and re-subscribing doesn't help because re-subscribe always hits the cache. See #2514.

Modifications:

• Disable cache by default;
• Provide API to opt-in for caching (can be useful if users resolve per new connection instead of polling in the background);
• Deprecate minTTL, remove maxTTL builder methods, introduce ttl(min, max) and ttl(min, max, minCache, maxCache) instead;
• Invoke ttlCache.prepareForResolution(name) only for scheduled queries, keep it unchanged when cancel/re-subscribe to correctly offset ttl;
• Ignore empty list inside MinTtlCache.get(...);
• Make DefaultDnsClient logging more consistent;
• Include id in the returned ServiceDiscoverer.toString() from the builder;
• Enhance testing;

Result:

Caching is disabled by default. Polling is driven by TTL. In case of re-subscribe, we always send a new query. Users have API to configure min/max polling intervals and caching.

[daschl]

If we start using a new method, consider using Duration instead of int seconds

[daschl]

Also, should we add a different builder for the caching enable/disable?

[idelpivnitskiy]

RFC defines TTL in seconds and returned result from the server is always in seconds. Feels more natural for DNS to think about the configuration the same way. It's hard to imagine when caching for 5.5 seconds will make more sense vs 5 or 6 seconds.

For a separate method for caching enable/disable is a good question. I keep thinking about what will be the best for users in both modes that we offer: poll DNS vs resolve per new connection. For the polling cache is usually not required, but a short caching for <5 seconds can help when you have multiple clients for the same IP. For the 2nd case cache is more important, but for how long we should cache by default is a question. We can have 2 "global-a" resolvers: one for polling, one for per-connection resolutions OR we can have one with larger polling interval and smaller caching interval. WDYT about having 2 method like:

.pollTtl(min, max)
.cacheTtl(min, max)

Users who want to disable cache will be able to set cacheTtl(0, 0), for polling the min allowed number can be either 1 or 0.

We can discuss more offline.

[idelpivnitskiy]

As we discussed offline, I went with:

.ttl(min, max)
.ttl(min, max, minCache, maxCache)

Thanks for brainstorming!

[idelpivnitskiy]

Build failures will be resolved after #2523 is merged.