Improve global-cached-lookups metric reporting

[zachjsh]

It was found that the namespace/cache/heapSizeInBytes metric that tracks the total heap size in bytes of all lookup caches loaded on a service instance was being under reported. We were not accounting for the memory overhead of the String object, which I've found in testing to be ~40 bytes. While this overhead may be java version dependent, it should not vary much, and accounting for this provides a better estimate. Also fixed some logging, and reading bytes from the JDBI result set a little more efficient by saving hash table lookups. Also added some of the lookup metrics to the default statsD emitter metric whitelist.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[kfaraz]

You could also consider doing this instead:

druid/processing/src/main/java/org/apache/druid/segment/StringDimensionDictionary.java

Lines 41 to 47 in 346fbf1

	@Override
	public long estimateSizeOfValue(String value)
	{
	// According to https://www.ibm.com/developerworks/java/library/j-codetoheap/index.html
	// Total string size = 28B (string metadata) + 16B (char array metadata) + 2B * num letters
	return 28 + 16 + (2L * value.length());
	}

[zachjsh]

Thanks for pointing this out! The I think depends on the particular version of java and beyond that the particular distribution of it. In my testing I found 40 bytes to be a good estimate for overhead. Sometimes I find that its a bit less. Will leave as is unless you feel strongly about changing.

[kfaraz]

I think we can proceed with what you have. It's a difference of just 4 bytes (40 vs 44) per String anyway, and as you mention, it does depend on java version.

[abhishekagarwal87]

it's better to use the same calculation and code.
@zachjsh - can you reuse the code? The common code can be placed in StringUtils class.

[kfaraz]

LGTM