[ISC-support #17264] ADB overmem cleaning strategy is too arbitrary

I've labeled this as a "Feature" because the current behavior has been in use "forever" and thus can be considered to be a "baseline" behavior.

The current overmem cleaning behavior, as I understand it, is that when a new entry is added up to two other entries in the same hash bucket are flagged with ENTRY_IS_DEAD. This makes a semi-arbitrary choice based primarily on the convenience of not needing to acquire any additional locks.

This method, though, can cause significant impairment for a resolver.

For example, consider a zone is served by two servers - one with low latency and EDNS support and the other with high latency and broken EDNS support.

It is most likely that these two entries will fall into different hash buckets, and theoretically each of those hash buckets have the same chance of triggering the overmem cleaning by having a new entry added to them.

This means that there's a 50% chance that ADB will "forget" about the preferred server. Then, until the ADB for the other address either expires or is likewise purged, BIND will exclusively use only the high-latency server with broken EDNS support.

One of the first tasks on this issue will be attempting to identify a full set of desirable characteristics for the overmem cleaning behavior.