Don't include RRsets with TTL=0 in when preserving cache content for use by the serve-stale feature

Per Support ticket #16297, even if serve-stale functionality is disabled, versions of BIND that have this feature will still observe max-stale-ttl and maintain a cache of expired content in case of emergency. In an emergency, serve-stale can be toggled 'on' via rndc - in which case access to relatively recently expired cache content would be very desirable ('you don't know you want it until it's gone!').

However, it doesn't seem at all reasonable to apply this same logic to RRsets that have been received with TTL=0.

In BIND, they are added to cache because this is the way the BIND architecture works - with server side that corresponds with clients and a resolver-side that does back-end fetching and puts the answers in cache for retrieval, even if they're for single-use only (TTL=0).

I assert that authoritative providers of TTL=0 RRsets are doing so because these are dynamic answers and they do not want resolvers to cache them. So therefore it makes no sense at all to preserve them and serve them stale if the authoritative servers become unreachable. Depending on specific scenarios, retaining TTL=0 RRsets could also cause unexpected cache bloat.

Please can we address this in all versions of BIND that have serve-stale functionality in their cache management.