[pkg/ottl] Accessors for profile attributes

[rockdaboot]

Description

Adds support for profile.attributes to OTTL.

This allows users to use profile.attributes without deeper knowledge of the protocol internals.
Currently, users have to deal with attribute_table and attribute_indices, which is error-prone and fragile when the experimental profiling signal changes internal representation.

This change depends on open-telemetry/opentelemetry-collector#12798 and thus includes that PR. It will be removed as soon as possible.

The profiles support for the transformprocessor currently relies/waits on this change.

[edmocosta]

Please mark it as ready for review when open-telemetry/opentelemetry-collector#12798 gets merged. Thanks.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 14 days.

[rockdaboot]

@edmocosta The pdata PutAttribute function now has been merged and adopted in this PR.

I'd still wait for #39952 until marking this PR as ready to review.

[edmocosta]

Hi @rockdaboot, #39952 is already merged, could you please update the branch and mark it as ready for review? Thank you!

[edmocosta]

It looks good to me, thanks for working on that and I'm sorry for the reviewing delay.

Regarding the profile dictionary, whenever I set an attributes it creates another entry on the attributes tables and updates the profile's attributes indices, which I guess is expected as we might have the same key with different values used by different profiles. My only concern is how the transform processor, for example, will impact the size of that table, considering that it happens even when I set the same profile's attribute key. For example, the following statements would generate two profile attributes table entries:

- set(attributes["newKey"], 1)
- set(attributes["newKey"], 2)

I guess it's okay, but I'm wondering if future lower contexts, that will run it in a loop, could become an issue, as this table would grow very quickly depending on the users statements. Just a thought, I understand you cannot tackle it on this PR, but just wanted to double check this behavior.

[rockdaboot]

It looks good to me, thanks for working on that and I'm sorry for the reviewing delay.

Regarding the profile dictionary, whenever I set an attributes it created another entry on the attributes tables and updates the profile's attributes indices, which I guess is expected as we might have the same key with different values used by different profiles. My only concern is how the transform processor, for example, will impact the size of that table, considering that it happens even when I set the same profile's attribute key. For example, the following statements would generate two profile attributes table entries:

- set(attributes["newKey"], 1)
- set(attributes["newKey"], 2)

I guess it's okay, but I'm wondering if future lower contexts, that will run it in a loop, could become an issue, as this table would grow very quickly depending on the users statements. Just a thought, I understand you cannot tackle it on this PR, but just wanted to double check this behavior.

Yes, that is expected atm. The table is a set of (unique) k/v pairs.
To automatically clean up unused entries, we would need something like a reference counter (and then re-use table entries with no reference).
Or as an expensive alternative, walk through all attribute index arrays to re-create the table.

But nothing we can tackle in this PR.