profiles: remove default_sample_type

[felixge]

This resolves the ambiguity when a ScopesProfiles message contains
more than one profiles entry matching the default_sample_type.

Also add a comment to clarify which profile viewers should display by
default. This was previously also ambiguous.

This change creates a minor problem when it comes to ensuring that pprof
profiles can round-trip through otel conversion as it may require the
ScopeProfiles.profiles entries to be reordered in order to honor the
default_sample_type of the original pprof message. Naively converting
the resulting otel profile back to pprof would cause the order of
Profile.sample_types to be changed.

Merging this change indiciates consensus within the profiling group that
this issue should be handled by adding a pprof.profile_order attribute
(name TBD) to the ScopeProfiles.attributes during the initial
pprof->otel conversion. This label will allow converting the resulting
otel profile back to pprof without any information loss.

See gh-633 for additional details.

[reyang]

@felixge might be good to have a changelog entry?

[aalexand]

@felixge might be good to have a changelog entry?

The profiling signal is still experimental and WIP, we don't add changelog entries for its changes right now. We will start doing this once 1.0 version is out.

[felixge]

In the last SIG meeting I promised that I would provide an example of how a pprof.profile_order (name TBD) label could be used to ensure that we can round trip pprof files without information loss.

Example pprof input (inspired by the Go memory profiles, but simplified):

# Profile
sample_type: [
  {type: "allocations", unit: "bytes"},
  {type: "allocations", unit: "count"},
],
default_sample_type: "allocations/count",
samples: [
  {value: [320, 10]},
  {value: [640, 2]},
],

Converted to OpenTelemetry:

# ProfilesData
resource_profiles: [
  {
    scope_profiles: [
      scope: {
        attributes: [
          {key: "pprof.profile_order": [1, 0]},
        ],
      },
      profiles: [
        {
          sample_type: {type: "allocations", unit: "count"},
          sample: [
            {values: [10]},
            {values: [2]},
          ]
        },
        {
          sample_type: {type: "allocations", unit: "bytes"},
          sample: [
            {values: [320]},
            {values: [640]},
          ]
        }
      ],
    ],
  },
]

This should round trip back to the original pprof file.

However, there is a small ambiguity here when default_sample_type is omitted. pprof says that in this case, clients should default to the last sample (type?) value. We will probably need an additional or more complex label if we want to round trip pprof files that omit the default_sample_type field precisely.

Anyway, I don't think this is a blocker for this PR. It's certainly a solvable problem.

[felixge]

This should be ready for merge now 🙇 . My force-push was a rebase.