[pkg/ottl] Add ParseSeverity function

[bacherfl]

Description

This PR adds the ParseSeverity function, as discussed in the linked ticket. I also had to make a minor change to the
internal mapGetter, handling the map literals to return a raw map[string]any, instead of a pcommon.Map. This is because if there is a map literal within a slice, the pcommon.Slice.FromRaw cannot handle the pcommon.Map, as it only works with raw data types.

This change is however transparent, and the behavior to the outside of this package does not change.
EDIT: After merging main with the support for value expressions, introduced in #36883, this would affect the type of values returned by ParseValueExpression - previously this could potentially return map[string]any/[]any, but with the changes introduced in this PR, this would return a pcommon.Map/pcommon.Slice.
Please let me know if I should do this change in a separate PR though.

Link to tracking issue

Fixes #35079

Testing

Added unit and e2e tests

Documentation

Describe new function in the readme

[github-actions]

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

[TylerHelmuth]

@bacherfl is this still draft?

[bacherfl]

@bacherfl is this still draft?

@TylerHelmuth Right now this is blocked by #37408 so I left it as draft for now. Once that other PR has been merged this should be ready though

[atoulme]

Ready for review by codeowners: @TylerHelmuth, @kentquirk, @bogdandrutu, @evan-bradley, @edmocosta please review.

[edmocosta]

@bacherfl is it ready for review? description says it's still in progress.

[bacherfl]

@bacherfl is it ready for review? description says it's still in progress.

yes - i forgot to update the description, but it is ready

[TylerHelmuth]

I dont understand how this is validating.

[bacherfl]

yes the name of the function was not accurate, I renamed it now. But speaking of validation - do you think it would be better to validate the full mapping at the beginning of the function, or rather return an error when we run into an error during the evaluation of the log level?

[TylerHelmuth]

We can't validate the map statically during startup, so I think returning errors when we encounter something unexpected is the right thing to do since it is more efficient.

[TylerHelmuth]

Also, why do we need to decode? I think we can check the type of the value when we try to use it and if it isn't a []any then we error.

Also would we need to check of other slice types? if the underlying value is a []string than it wont be considered a []any.

[edmocosta]

TBH, I found this function's usage a bit confusing, and I'm not sure how it would scale if we decide to add new options. I think it would be clear (and more scalable) if we named the conditions types, for example

The current mappings:

ParseSeverity(severity_number, {
       "error":["err", { "min": 3, "max": 4 }],
       "info":[{ "min": 1, "max": 2 }],
     }
))

Could be expressed as:

PaseSeverity(severity_number, {
     "error": [{"equals": "err"}, {"range":[3,4]}],
     "info":  [{"range":[1,2]}],
})

With condition names, it's clear for me that the loose "err" string is an "equals" condition, and that the map with min and max key is a "range" condition (even if expressed as [2]int). It also makes it easy for introducing other conditions types in the future, such as "contains", "regex", etc.

Another future possibility would be supporting the AND operator by grouping conditions in the same map, being each key a condition, for example:

PaseSeverity(severity_number, {
     "error": [{"equals": "err", "range":[3,4]},  {"range":[5,6]}],
})

Just sharing my thoughts and opening it for discussion. If we don't have further plan for this function, it would be fine as it's (although naming the conditions would simplify the code, I guess).

[bacherfl]

Just sharing my thoughts and opening it for discussion. If we don't have further plan for this function, it would be fine as it's (although naming the conditions would simplify the code, I guess).

@edmocosta the goal here was to use the same structure as the severity parser in stanza: #35079 (comment)

[edmocosta]

Just sharing my thoughts and opening it for discussion. If we don't have further plan for this function, it would be fine as it's (although naming the conditions would simplify the code, I guess).

@edmocosta the goal here was to use the same structure as the severity parser in stanza: #35079 (comment)

I'm sorry for the noise, I probably misunderstood it and I thought the goal was having the same stanza functionality, and not exactly replicate the same configuration structure. I'm still don't understand why that should be a requirement, but if you folks agreed on that, I'm fine. Thanks for clarifying.