[pkg/ottl] Add function ProfileID()

[rockdaboot]

Description

Add the OTTL function ProfileID(), which is currently missing.

[florianl]

A profile_id with all zeroes is considered invalid. Should the example be updated to show a valid profile_id?

https://github.com/open-telemetry/opentelemetry-proto/blob/42319f8b5bf330f7c3dd4a097384f9f6d5467450/opentelemetry/proto/profiles/v1development/profiles.proto#L238-L242

[rockdaboot]

Interesting, why is this field "required" (at least one bit must be set)?
I'd say that a receiving backend service can operate without a profile_id.

[rockdaboot]

Changed to a valid ProfileID

[edmocosta]

Wouldn't allowing empty profiles be useful for verifying if some profile_id (pprofile.ProfileID) field is empty? It seems the empty rule also applies to trace and span IDs, but their converters are not restricting creating empty values.

[rockdaboot]

It's possible to construct uses cases supporting both options. But I'd say that's a decision of the profiling SIG. If there are real-world use-cases that need an empty profile_id, this needs to be discussed in the SIG and then clarified in the protobuf definition and docs.

span_id is optional: https://github.com/open-telemetry/opentelemetry-proto/blob/f24da8deeb50118271c9435972791ef05ec003b1/opentelemetry/proto/logs/v1/logs.proto#L205

trace_id is optional: https://github.com/open-telemetry/opentelemetry-proto/blob/f24da8deeb50118271c9435972791ef05ec003b1/opentelemetry/proto/logs/v1/logs.proto#L192

profile_id is required: https://github.com/open-telemetry/opentelemetry-proto/blob/f24da8deeb50118271c9435972791ef05ec003b1/opentelemetry/proto/profiles/v1development/profiles.proto#L247

[edmocosta]

I didn't mean making the profiles proto profile_id field optional neither making it accepting zeroed values.
My point is, should we allow using the ProfileID(...) function with zeroed byte array? Taking the examples you showed, trace_id and span_id are optional fields in the Logs proto, so they can be empty at some point, but on the other hand they're also required on the traces proto.

That said, IMO:

• If having empty profile IDs (as fields of other protos) is/will be a possibility, so the function shouldn't restrict creating empty profiles IDs. It allows users filtering by, and cleaning the field values if they want: span_id == SpanID(0x0000000000000000), set(span_id, SpanID(0x0000000000000000)).
• profile_id path setters should ensure that non-zeroed profiles are set to the profiles proto, not the converter function.

[rockdaboot]

Now I get you, makes sense! :)
Removed the check for the converter functions and create a new PR for not allowing to set empty ProfileIDs via the OTTL accessor.

[rockdaboot]

New PR to disallow setting empty profile ids: #39659

[edmocosta]

Could you please add an e2e test for the new converter? similar to the existing SpanID.