[pkg/ottl] Fix replace functions for profiles

[rockdaboot]

Component(s)

pkg/ottl

Describe the issue you're reporting

Background
The profiles signal uses indices + lookup table instead of an array or map.

For example, pprofile.Profile contains a lookup table of attributes (AttributeTable), which is referenced by an array of indices (AttributeIndices).

During the work on the transformprocessor ([draft PR(https://github.com//pull/39036)), it turned out that a typical accessor/getter for attributes would return a pcommon.Map. The OTTL functions then change this map and pass it to the accessor/setter.

Problem
Some of the OTTL functions assume that changes to the attributes map returned by the getter automatically change the profiles data without calling the setter.
For example here
So the changes are never written to the pprofile.Profile in this case.

Possible solution
Just from my limited knowledge... better solution possibly exist.

• identify all places were this assumption is wrong
• change the OTTL functions signature to take a GetSetter instead of a Getter and call the setter.

cc @TylerHelmuth

[github-actions]

Pinging code owners:

• pkg/ottl: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley @edmocosta

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[rockdaboot]

Created an initial draft PR for further discussions: #39416

[edmocosta]

Thank you very much for bring this issue up, @rockdaboot!

I'm not pretty sure why we've editor functions using ottl.PMapGetter[K] instead of ottl.GetSetter[K], and IMO it seems to be an issue, as those editors are leveraging the object’s reference to change their values, and consequently generating problems like this one you described.

Another difference is that ottl.GetSetter[K] only works with context’s paths (which makes sense, as they’re meant to change data), while the ottl.PMapGetter[K] also works with map literals. Personally, I'd rather raise an error if an editor is used with literals than letting it run a no-op statement.

For example, why should we support change literal values with editors if the result gets lost (see example), am I missing some use-case?

log_statements:
 - context: log
   statements:
    - 'replace_all_patterns({"foo": "bar"}, "key", "bar", "test")'

That said, I think one idea would be replacing those editor PMapGetter usages with GetSetter, so it would prevent the issue described and also avoid its usage with literals (see append example). It would also be a breaking change, but I think it might be acceptable:

log_statements:
 - context: log
   statements:
    - append([], [1, 2, 3])

 error while parsing arguments for call to "append": invalid argument at position 0: must be a path

@TylerHelmuth @evan-bradley WDYT?

[TylerHelmuth]

@edmocosta I like your idea

[rockdaboot]

I updated the PR to implement the idea from @edmocosta, just left two comments there that would help to undraft the PR.

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• pkg/ottl: @TylerHelmuth @evan-bradley @edmocosta

See Adding Labels via Comments if you do not have permissions to add labels yourself.