Create a oneof for Histogram buckets; add ExplicitBuckets; deprecate DoubleHistogram

[jmacd]

This deprecates the existing DoubleHistogram and creates a new one with room for more histogram types to be added in the future.

The oneof proposed here was first described in the issue #259 (comment) and has support from contributors working on #226, e.g., #226 (comment).

Fixes #259.
Alternate to #255.

[bogdandrutu]

@jmacd and some folks had an offline chat, and I want us to make a decision between multiple bucket types vs multiple histogram types:

• Pros for this: Simplify the number of types we will have in the metrics.
• Cons for this: Extra allocations (one extra allocation in every point); Have to deal with a corner case where points have different bucket types.

[jmacd]

Extra allocations (one extra allocation in every point)

These allocations will be real costs in the collector, but they're not a big deal in SDKs where the export frequency is relatively low.

A fancy protocol buffer implementation would help, for the collector case.

Have to deal with a corner case where points have different bucket types

Note that in #264 (comment) is a proposal to place parallel repeated fields into the Gauge, Sum, and Histogram points to reflect number-type variation. In #259, you propose to add per-bucket-style Histogram value types to the Metric oneof, where such variation currently resides. If we follow @victlu's proposal for histograms, to be consistent, we should place the parallel repeated fields inside a single Histogram. Note @victlu as you may be prototyping, we no longer desire to support number-type variation for histograms, but we do intend to support bucket-style variation. @bogdandrutu do you think it would reduce complexity if the (single) Histogram point had parallel fields, as follows?

message Histogram {
  AggregationTemporality aggregation_temporality = 2;

  repeated ExplicitHistogramDataPoint explicit_data_points = 1;
  repeated ExpontentialHistogramDataPoint exponential_data_points = 3;
}

In both cases, with number-type variation and with bucket-style variation, we do not see a semantic conflict but there is loss of information if we convert between them. By supporting parallel fields we reduce the number of overall oneofs, and we prevent users from having to observe parallel histograms or sums/gauges when there is only bucket-style or number-type variation. We avoid an allocation (however the points are correspondingly larger by 24 bytes in the collector case.).

[hdost]

Is the ExpontentialHistogramDataPoint the concept of the "HDR" histogram. As i believe the explicit bounds could technically hold a set of Exponential buckets as well.
Perhaps instead DynamicHistogramDataPoint, SparseHistogramDataPoint or something to that effect.

[yzhuge]

@hdost Exponential buckets will handle high dynamic range. It is different from http://hdrhistogram.org/ in that http://hdrhistogram.org/ use "log linear" (linear subbuckets in log buckets), while Exponential will use log buckets only, for wider compatibility. We might add support for log linear in the future.

[yzhuge]

See open-telemetry/oteps#149 (Add exponential bucketing to histogram protobuf)
The new format is cleaner and simpler than the one proposed in #226, because the count array is no longer shared across bucket formats

[jmacd]

@open-telemetry/specs-metrics-approvers note this PR fully incorporates #270.

[jmacd]

We have decided to let each distinct form of histogram have its own data point kind.