[ISC-support #17264] revisit hard-coded limit to ADB sizes with shared caches

Currently when using a shared cache the ADB size is limited by a #define constant. This is documented as being done to allow an operator to specify a huge shared cache size without automatically allowing a similarly-huge ADB for each view attached to that cache.

There are some assumptions here that I believe may be incorrect.

The first incorrect assumption (and verifiable at that) is that BIND will continue to behave well when an ADB is overmem. Analysis on recent customer core files has determined that an overmem ADB may start to "thrash" impacting resolver performance (as noted by the customer's system monitoring).

A second assumption is that there will be enough differences between the query/recursion patterns for each view that no one view will have to worry about possibly needing to have ADB entries for every upstream nameserver. This is clearly false in the degenerate case of a single view using an attached cache, but even with multiple actual views this makes assumptions about how the operator is dividing up the query traffic that are unlikely to always be true.

If #2438 is completed then it may be sufficient to exempt an explicitly configured ADB size from this check. Other possible solutions include allowing this #define to be overridden at build-time or using a different scaling formula for shared caches than is used for exclusive caches.