profile: drop duplicate field in message Profile

[florianl]

The message Profile contains two fields of type opentelemetry.proto.common.v1.KeyValue, attribute_table and attributes. Both fields are intended for the same use. Therefore drop the later one.

ping @open-telemetry/profiling-maintainers @jhalliday

[jhalliday]

yes, not actually duplicates. The attributes_table is there to be referenced by fields of attributes in other places as a de-duplication / size reduction measure, whereas the attributes field is for things that belong directly to the profile itself. It would be correct, though not especially useful, to make the attributes field a repeated int indexing into the attributes table, but removing it entirely is not appropriate.

[florianl]

Thanks for the feedback. The differences between attribute_table and attributes were not clear, so that gave me the impression of a duplicate field. To address your feedback, I have added attribute_indices with bcfb44e for the global attributes in message Profile, that can reference into attribute_table.
This should help differentiating the attributes while having only a single attribute_table which also helps to deduplicate elements.

[aalexand]

Do we want to simply reuse the field ID of the removed field maybe? It's not a backward compatible change, but we recently did a field renumbering and I assume before releasing version 1 we'd want to make sure we don't have ID gaps, so we might as well do this now. @jhalliday WDYT

[florianl]

For the moment I would vote for just using a new field ID and not reuse the existing one, change its field name and field type. Before declaring this proto as stable, closing these gaps make sense, but I think this will still take a while.

[aalexand]

SGTM

[jhalliday]

@dmathieu does this have the potential to cause headaches in the collector? Adding attributes to the 'top level' entity in a given signal type seems like one of the most common mutations in the collector pipeline use cases and I think all the others use common.v1.KeyValue and hence probably have shared pdata golang types/code for doing so. Are we adding undue complexity here if profiles works a different way?

[dmathieu]

Processors should be able to get a command to "add an attribute to a profile/sample", and have that turned into the proper append/find in the attributes table, and indices.
So I don't think it's so much of an added complexity.

It's true that the entirety of these mapping tables are pretty unique to profiles, and none of the other signals use it though, making profiles rather a snowflake.