FQDN: pick some low-hanging performance fruit

[squeed]

This fixes some low-hanging-fruit, performance-wise, of the FQDN subsystem. It introduces a benchmark that stresses NameManager.UpdateGeneratedDNS(), which is in the critical path (and behind a lock!) for returning DNS responses.

The changes are:

1. Use sets.Set for determining IP uniqueness. This allocates a bit more memory, but has the advantage of many fewer allocations
2. Don't sort unnecessarily. We were doing a lot of unnecessary sorts in the DNSCache. These are only needed for tests, so just axe 'em.
3. Don't build an expensive logrus.Fields object just to skip at non-Debug level.

Benchmark results:

                     │ bench/00.out │            bench/01.out            │
                     │    sec/op    │   sec/op    vs base                │
UpdateGenerateDNS-12     3.558 ± 1%   2.157 ± 1%  -39.37% (p=0.000 n=10)

                     │ bench/00.out │             bench/01.out             │
                     │     B/op     │     B/op      vs base                │
UpdateGenerateDNS-12   902.9Mi ± 0%   532.1Mi ± 0%  -41.06% (p=0.000 n=10)

                     │ bench/00.out │            bench/01.out             │
                     │  allocs/op   │  allocs/op   vs base                │
UpdateGenerateDNS-12    9.034M ± 0%   1.009M ± 0%  -88.83% (p=0.000 n=10)

Optimize IP/FQDN management in the DNSCache

[gandro]

Aswesome, thanks! I'm a low confidence reviewer, but this looks good to me overall. Only one thing which is unclear to me.

I would also be curious to see benchmarks for different data set sizes. While I expect a hashmap to be more efficient for large-ish sets of IPs, I would also expect that if there is only a hand full IPs that the old slice+sort approach might be faster.

[joestringer]

/test