profiles: remove default_sample_type

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 the pprof
profiles can round-trip through otel conversion as it may require the
ScoeProfiles 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
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
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.

[gh-633]: #633 (comment)

Author: felixge

opentelemetry/proto/profiles/v1development/profiles.proto

@@ -139,6 +139,8 @@ message ProfilesData {
   // from non-containerized processes.
   // Other resource groupings are possible as well and clarified via
   // Resource.attributes and semantic conventions.
+  // Tools that visualize profiles should prefer displaying
+  // resources_profiles[0].scope_profiles[0].profiles[0] by default.
   repeated ResourceProfiles resource_profiles = 1;
 
   // One instance of ProfilesDictionary
@@ -182,10 +184,6 @@ message ScopeProfiles {
   // https://opentelemetry.io/docs/specs/otel/schemas/#schema-url
   // This schema_url applies to all profiles in the "profiles" field.
   string schema_url = 3;
-
-  // The preferred type and unit of Samples in at least one Profile.
-  // See Profile.sample_type for possible values.
-  ValueType default_sample_type = 4;
 }
 
 // Profile is a common stacktrace profile format.