Extract HDR histogram implementation into a shared package

[joanlopez]

What?

It extracts the HDR histogram implementation from the expv2 Cloud output package, into an internal but shared package, so it can be reused for our metrics.TrendSink implementation and/or (at the very least) for the Summary output.

Why?

Because as discussed and suggested here it's likely the best way to move forward. Plus, now that we're about to release a new major, it's likely a good moment to add this kind of breaking change (behavioral, not programmatic API).

Related PR(s)/Issue(s)

Related with #763

Notes for the reviewer(s)

To facilitate the review, I'd suggest to do a clipboard diff between the contents that were on expv2/hdr.go vs the new histogram/hdr.go. But to summarize, it's mostly about making the type and constructor public, and leaving the protobuf specific bits in the Cloud output package, because it feels like it's specific to that.

Also, note that I decided to create this histogram package inside a ds directory, standing for "data structures", but I'd be happy to either rename ds into something more explicit, and/or move histogram into a first level package inside internal. As it is internal, it should be fine to start this way and move into a ds package tomorrow if we ever add more data structures. Just tell me what you prefer.

[oleiade]

🚀 🎉

I think it makes sense to have a data structure specific package, for reusability, and to centralize a lot of the logic we might reuse over time. My only complaint is that I find the ds name implicit and if I were looking for histograms I wouldn't think "oh yeah, it's gonna be in that ds folder" :D, although I could live with it (non-blocking).

A more specific/explicit name I can think of for the package would be container in that sense it expresses that it contains data structures dedicated to containing data. But I could see a histogram package at the top level of internal.

[mstoykov]

I think it is fine to have it in a separate hdr/histogram package for now and later if we decide to have datastructure package to ... have it named that than ds.

But IMO we can do that later as well

[joanlopez]

Gonna merge it as-is, to move forward. As it is an internal package, we have freedom to adjust as needed later.