Define deep estimated-size accounting for generic sketch values

[tisonkun]

The existing estimated_size methods account for inline state and heap capacity directly owned by sketch implementations. For generic values, however, they cannot see heap allocations owned by the value itself.

The clearest example is CompactTupleSketch<S>: Vec<TupleEntry<S>> capacity includes the inline S value, but a summary such as String or Vec may retain arbitrary additional heap memory. Similar questions apply to generic Tuple operator state and, potentially, generic items in Frequencies.

One possible direction is a public EstimatedSize trait implemented by built-in value types and implementable by user summaries. Before choosing it, we should define:

• whether estimated_size is shallow or deep;
• whether size_of::() is included or only heap allocations;
• whether vector length or retained capacity is counted;
• how shared allocations are handled without double counting;
• whether allocator overhead is intentionally excluded;
• how methods remain available for generic types that do not implement the trait;
• whether a callback or an estimated_size_with method composes better than another public trait;
• whether serialization size and resident memory remain clearly separate concepts.

Related work: #135, #137, #174, and #177.

cc @Renkai @ariesdevil @tabac @notfilippo — you contributed to or reviewed the existing estimated-size work; input on a stable accounting contract would be valuable.

[ariesdevil]

Do we need to distinguish between resident memory size(shallow) and serialized size(deep)?

[tisonkun]

I think the method's name itself, "Estimated Size," means a certain degree of deviation is acceptable.

However, we should probably have a contract to evaluate exactly what it estimates; otherwise, if there's a large deviation, I think such an interface might be unnecessary.

Of course, we might not need to implement an estimated_size method for all sketches; this is an open issue.