rec: Compute size *estimate* for record cache allocated size

[omoerbeek]

Short description

This implements a better computation of the metric cache-bytes. The existing one neglected the size of the individual records.
This one might overestimate in some cases (string storage in string object itself) and underestimate because malloc bucket sizes, but at least it takes into account variable sized records.

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[coveralls]

Pull Request Test Coverage Report for Build 12768425464

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 92 of 231 (39.83%) changed or added relevant lines in 5 files are covered.
• 67 unchanged lines in 12 files lost coverage.
• Overall coverage decreased (-9.2%) to 64.887%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pdns/recursordist/recursor_cache.cc	31	35	88.57%
pdns/dnsparser.hh	0	6	0.0%
pdns/dnsrecords.hh	40	169	23.67%

Files with Coverage Reduction	New Missed Lines	%
pdns/packethandler.cc	1	72.74%
pdns/recursordist/lwres.cc	2	69.66%
pdns/recursordist/sortlist.cc	2	72.94%
modules/lmdbbackend/lmdbbackend.cc	2	72.75%
pdns/rcpgenerator.cc	2	90.55%
pdns/misc.hh	3	87.62%
modules/godbcbackend/sodbc.cc	4	70.8%
pdns/recursordist/pdns_recursor.cc	4	72.62%
pdns/recursordist/syncres.cc	5	80.33%
pdns/signingpipe.cc	5	86.06%

Totals
Change from base Build 12765482410:	-9.2%
Covered Lines:	126445
Relevant Lines:	164072

---

💛 - Coveralls

[rgacogne]

One question but it looks very good!

[rgacogne]

I don't quite get the last part of the calculation here?

[omoerbeek]

The idea is: a set represented as a tree has size() nodes. Each node is at least 2 bytes (to store the uint16_t value) plus the internal node data, which is estimated as being the roughly same size as the head node of type std::set<uint16_t>. Come to think of it, the 2U is redundant as it is already included in sizeof(std::set<uint16_t>. I'll check if there is a better estimate possible.