[bug] Wrong buckets when Infinity is provided as boundaries

[reyang]

Package

OpenTelemetry

Package Version

Package Name	Version
OpenTelemetry.Api	1.10.0-beta.1.31
OpenTelemetry	1.10.0-beta.1.31

Runtime Version

net8.0

Description

When Infinity is provided as part of the explicit buckets, OpenTelemetry SDK will produce wrong buckets.

Steps to Reproduce

using System.Diagnostics.Metrics;
using OpenTelemetry;
using OpenTelemetry.Metrics;

namespace CustomizingTheSdk;

public class Program
{
    private static readonly Meter Meter = new("CompanyA.ProductA.LibraryA", "1.0");

    public static void Main()
    {
        using var meterProvider = Sdk.CreateMeterProviderBuilder()
            .AddMeter(Meter.Name)
            .AddView(instrumentName: "MyHistogram", new ExplicitBucketHistogramConfiguration() { Boundaries = new double[] { 0, double.PositiveInfinity } })
            .AddConsoleExporter()
            .Build();

        var random = new Random();


        var histogram = Meter.CreateHistogram<long>("MyHistogram");
        for (int i = 0; i < 20000; i++)
        {
            histogram.Record(random.Next(1, 1000), new("tag1", "value1"), new("tag2", "value2"));
        }
    }
}

Expected Result

The output should have 2 buckets instead of 3 buckets.

(-Infinity,0]:0
(0,+Infinity]:20000
(0,+Infinity]:0 <------------- THIS ONE SHOULD NOT BE HERE

Actual Result

Metric Name: MyHistogram
(2024-10-30T19:51:28.7995925Z, 2024-10-30T19:51:28.8465486Z] tag1: value1 tag2: value2 Histogram
Value: Sum: 10037594 Count: 20000 Min: 1 Max: 999 
(-Infinity,0]:0
(0,+Infinity]:20000
(0,+Infinity]:0

Instrumentation scope (Meter):
        Name: CompanyA.ProductA.LibraryA
        Version: 1.0
Resource associated with Metric:
        telemetry.sdk.name: opentelemetry
        telemetry.sdk.language: dotnet
        telemetry.sdk.version: 1.10.0-beta.1.31
        service.name: unknown_service:customizing-the-sdk

Additional Context

I guess the same issue might exist for Advice and other scenarios. It seems to me that in general the IEEE 765 subnormal numbers are not properly handled/tested across the SDK.