[pkg/ottl] Standardize grammar slices from raw to `pcommon.Slice`

[edmocosta]

Component(s)

pkg/ottl

Is your feature request related to a problem? Please describe.

The OTTL grammar currently handles slices inconsistently, producing either Go's raw slices ([]any) or pcommon.Slice depending on usage and whether the value comes from a literal or a function. To avoid unnecessary conversions from raw slices to pdata, and to ensure consistency, we should standardize all slices to pcommon.Slice, similar to the approach taken for maps.

Note: This is a breaking change for the OTTL API.

Important

This is not a trivial issue. Please don’t just vibe-code it. Make sure you understand how the OTTL core works and what changes are required to implement this properly.

Describe the solution you'd like

Slices produced by the OTTL grammar are pcommon.Slice, and it's fully handled by ALL existing getters, contexts, etc.

Describe alternatives you've considered

No response

Additional context

• More context on the maps standardization can be found at: [pkg/ottl] adapt mapGetter to handle nested map items within slices #37408

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

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

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

[Rajneesh180]

The core change is in listGetter.Get() — build a pcommon.Slice instead of []any, handling nested pcommon.Map/pcommon.Slice elements via CopyTo, same pattern mapGetter already uses. That ripples into mapGetter's nested list handling and sortConvertedSlice's return type.

Everything else (compare.go, SetValue, func_append, func_sort input handling) already has pcommon.Slice code paths that just don't get exercised by grammar-produced lists today. I'd keep the []any fallback cases for backward compat with external functions — @edmocosta is that the right call or should those get cleaned up too?

One thing worth verifying: comparePSlice uses a.Equal(v) while compareSlice uses reflect.DeepEqual(a, v.AsRaw()) — should be semantically equivalent but want to confirm before changing which path grammar lists take.