[pkg/ottl] Add support for lists as Getter values

[evan-bradley]

Description:

Allow using lists as a Getter value. This implementation implements a listGetter struct that allows recursively evaluating list elements, which allows putting paths and invocations in lists.

Link to tracking Issue:

Fixes #16320

Testing:

Added unit tests to check for this functionality at multiple levels.

Documentation:

The existing docs should cover this functionality.

[evan-bradley]

@TylerHelmuth This implementation is different than what we discussed, but will allow for using paths and invocations in lists. The downside is that the lists can be probably unnecessarily complicated, and we can't easily enforce that they are homogeneous, which is required by the specification for Attribute values. There are other places in the OTTL where users can cut themselves, so this seemed like an acceptable tradeoff.

[TylerHelmuth]

we can't easily enforce that they are homogeneous, which is required by the specification for Attribute values

@evan-bradley I wasn't aware that array values for an attribute had to be homogenous. I was checking the spec earlier for something I was working on and this section reads to me like arrays can be a mix of values.

[TylerHelmuth]

will allow for using paths and invocations in lists

This is definitely needed, good catch.

[evan-bradley]

I wasn't aware that array values for an attribute had to be homogenous. I was checking the spec earlier for something I was working on and this section reads to me like arrays can be a mix of values.

When working on this, I found two places where the proto AnyValue was used:

• Attribute values that are arrays are required to be homogeneous arrays by the specification. While OTLP does support heterogeneous arrays for attribute values, the API implementations will only accept and emit attribute values that are homogeneous arrays.
• Logs support heterogeneous arrays in the body field to support existing log models, but advises a string type for new implementations.

I would prefer that the Collector didn't intentionally emit any data in a format that would be disallowed for an OpenTelemetry language API, since it is likely for data that isn't spec-compliant to be handled inconsistently or simply dropped by backends. I don't think the Collector is technically bound to abide by the specification to that degree, so I don't think we are required to do anything in this case.

I think if we do decide to validate that attributes are only set to homogeneous arrays, we should probably do it in the contexts.

[TylerHelmuth]

Good info, thanks for pointing out those API requirements. I agree, we should follow the spec so we don't produce any invalid data.

I agree that the contexts should be the enforcers. Within the contexts there are no Getters, just values, so it should be easy to check and enforce.

Can you open an issue to track this enforcement?

[TylerHelmuth]

LGTM

[evan-bradley]

Can you open an issue to track this enforcement?

See #16355.

[bogdandrutu]

Needs a rebase