The value for Sample.stacktrace_id_index is hardly defined except for its length. It is also not defined how this value should be generated, interpreted and could be used.
Some kind of stacktrace_id can be most efficient in stateful protocols, where transmitting duplicate information should be avoided. As the OTel Profiling protocol is a stateless protocol, this element can be droped.
With `Mapping.filename`, `Function.name`, `Label.key` and others the type of the index into the string table is always of type `int64`.
For consistency align the type of `Location.type_index`, which is also an index into the string table, to `int64`.
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Gah, we put java_package on one file but not the other. Oops.
Apparently the opentelementry-proto-java artifact can't be consumed by opentelemetry-java without this.
This is a follow up to [OTEP 239: Introduces Profiling Data Model v2](https://github.com/open-telemetry/oteps/pull/239)
The main motivation behind this PR is that this will allow us to start experimenting with the profiles proto in opentelemetry-collector. I marked the profiles part as `Experimental` to indicate that this is not a final version of the data model.
I copied the proto from the OTEP, and moved `pprofextended.proto` from `profiles/v1/alternatives/pprofextended.proto` to just `profiles/v1/pprofextended.proto`. I did this because I figured we no longer have alternative representations and this will reduce confusion for people outside of Profiling SIG. The rest of the proto stayed the same.
I tested this file with a collector fork and I it compiles properly.
Florian Lehner
Long Yang
Jonathan Halliday
Dmitry Filimonov