Serve-stale implementation broke cache database RRset statistics

Serve-stale implementation (see commit df507515, RT #44790) changed the definition of a "stale" rdataset header:

• in BIND 9.11 and earlier, a "stale" rdataset header is one that is more than RBTDB_VIRTUAL (a hard-coded value of 300) seconds past its TTL-based expiry time and thus is eligible for opportunistic cleanup,
• in BIND 9.12 and later, rdataset headers of the above type are known as "ancient"; meanwhile, a "stale" rdataset header is one which is past its TTL-based expiry time but not yet eligible for cleanup; a "stale" header becomes an "ancient" header once max-stale-ttl + RBTDB_VIRTUAL seconds pass since its TTL-based expiry time.

The BIND statistics system has been able to track "stale" rdataset headers (according to the BIND 9.11 definition) since commit 80fa3ef8 (see RT #29514). In the outputs of various statistics channels, such RRsets were prefixed with a # character.

Serve-stale implementation in BIND 9.12 introduced the following problems:

• As a corollary of the definition change described above, RRsets previously presented using the # prefix are no longer the same type of RRsets as before.

• The arrays holding statistics counters were not adjusted to account for the definition change, which means BIND stopped keeping track of "ancient" rdataset header counts altogether (such headers are processed and freed correctly but they do not affect statistics).

• Functions responsible for dumping statistics to various channels were not extended as no new DNS_RDATASTATSTYPE_ATTR_* macro was added, etc.

• Certain code comments were not updated to match the new nomenclature, which is guaranteed to cause quite a bit of confusion for new BIND developers.

• The rule for updating counters when an rdataset header is marked as "stale" (according the BIND 9.11 definition; the rule is: first decrement the number of "non-stale" records of given type, then increment the number of "stale" records of given type) no longer holds up: depending on query patterns, an rdataset header may either go through the entire "active" → "stale" → "ancient" cycle or go straight from "active" to "ancient". In other words, current rdataset header state needs to be consulted in order to determine which counters should be touched.

• No statistics counters are updated when an rdataset header is marked as "stale" (according to the BIND 9.12 definition).

Given all of the above issues and the fact that the default value of max-stale-ttl is non-zero, I would dare to say that cache database RRset statistics are more or less useless in BIND 9.12 and later.