profiles: avoid 'optional' keyword usage

[jhalliday]

Prefer reference tables with an explicit null/unused entry at index=0, rather than 'optional' pointers into the tables.

Following discussion in the profiling SIG, we note that other OpenTelemetry signal types don't use 'optional' protobuf fields and, whilst the Dictionary lookup tables pattern in the profile signal type require some form of 'null pointer' value for indicating unset indexes into the tables, the string_table convention inherited from pprof prefers table[0] = "" i.e. treats a 0 value pointer as null.

In the interest of improving consistency with other signal types and within the profiling signal itself, we therefore make mapping and link tables/references follow the same convention of having an explicit 'not used' default value as the first element in the dictionary table.

Note that I've chosen to not update the docs for the other dictionary tables to require the same use of the [0] slot, as at present no _index fields optionally reference into them, so I'm treating it as unnecessary at this time. However, it can be argued that greater clarity and consistency would be achieved by making the convention universal in anticipation before adoption becomes widespread and it gets harder to change.

[jhalliday]

@open-telemetry/profiling-maintainers

[felixge]

Thanks for the PR 🙇

Note that I've chosen to not update the docs for the other dictionary tables to require the same use of the [0] slot, as at present no _index fields optionally reference into them, so I'm treating it as unnecessary at this time. However, it can be argued that greater clarity and consistency would be achieved by making the convention universal in anticipation before adoption becomes widespread and it gets harder to change.

I'm in favor of considering this.

[florianl]

Thanks for working on this 🙏

[felixge]

@tigrannajaryan can you help us find a spec approver?

[jsuereth]

Note that I've chosen to not update the docs for the other dictionary tables to require the same use of the [0] slot, as at present no _index fields optionally reference into them, so I'm treating it as unnecessary at this time. However, it can be argued that greater clarity and consistency would be achieved by making the convention universal in anticipation before adoption becomes widespread and it gets harder to change.

@jhalliday can you open an issue for doing this work so it's not lost?