[pkg/ottl][draft] Update statements to reflect their context

[edmocosta]

Description:

This PR is a draft implementation of the issue: #29017, and introduces the necessary ottl and transformprocessor changes to make it possible for statements express their context via path names.

Please note that just a few unit tests were added at the moment, it's a WIP PR and the goal is to provide a full picture to the community and discuss the implemented solution. Individuals PRs will spawn from this draft, including extra changes, tests, docs, changelogs, etc.

Changelog

---

ottl/grammar

• It now parses the first path segment as the Context name, for example, the path foo.bar.field would be parsed as the following AST example: {Context: "foo", Fields: [{Name: "bar"}, {Name: "field"}]}, instead of {Fields: [{Name: "foo"},{Name: "bar"}, {Name: "field"}]}. This new logic is enabled/disabled by setting the parser option WithPathContextNames. When it's enabled, valid path's context are required.
• A new field Pos lexer.Position was added to the path object, it's handled/filled by participle lexer automatically, and is used to infer the statements path's context and for the appending missing context utility.

ottl/parser_collection (*new)

This utility is based on the existing transformprocessor's ParserCollection concept and is used to group context's parsers, abstracting the logic to infer the context from the statements, and/or rewriting them adding their paths's context if necessary.

In summary, the general idea is: given the configured contexts, parsers and statements converters, pick the right parser, and transform the parsed result (ottl.Statements[K]) into something common to the parser collection ([R]). For more details, please have a look at the transformprocessor refactoring using this utility.

Given ottl.Parse[K]r's have different type restrictions/generics (e.g. TransformContext), this utility heavily rely on the Go's reflection api, being the exposed interface type-safe, but manipulating untyped objects under the hood.

Considering this code is only executed during the bootstrap, IMO, it should be fine using reflection. I couldn't think about any other solution that would make this utility as generic as it's with reflection. Another approach would be hard-code all the existing ottl contexts's parsers on the collection, having fixed WithParserX functions per context and generating a direct dependency on the ottl/contexts package.

Suggestions are very welcome!

ottl/context_inferrer (*new)

This utility's goal is to infer the context from the provided statements. To do so, it extract all the statements's path, comparing the path.Context values, and choosing the highest one according to the provided context names list order.

Topics to consider/discuss:

• The default inferrer implementation - by default - does not skip unknown contexts, it only take them from the paths, and prioritise it based on the oder list, which does not necessarily need to contains all found contexts. In summary, if the statement is invalid, it might return a value that's not a valid context for the parser/parser collection. For example, if the statement only contains a path like foo.bar , and the order list is [span, spanevent], it would return foo. Either way, that shouldn't be an issue considering the statement is invalid and an error will be raised.

statement rewrite utility (*new)

A new function was added to the Parser[K] (AppendStatementPathsContext), which main goal is to take a statement without path's contexts and append the main context value to it. Path's which context value matches any parser WithPathContextNames are not modified.

Under the hood, it relies on the new grammar path's field Pos lexer.Position to insert the missing context names.
For now, this utility is being used by the parser collection ParseStatementsWithContext function, which purpose is to parse "old" style statements, which path's does not contain the context prefix.

transformprocessor

It was refactored to use the new parser utilities and to support mixed configuration styles, example:

trace_statements:
  - set(span.status.code, 1) where span.attributes["http.path"] == "/health"
  - set(span.status.code, 1) where span.attributes["http.path"] == "/health"
  - context: spanevent
     statements:
       - set(attributes["domain"], "test.com")

• When the flat configuration mode is used, it requires statements's paths to have a valid context prefix, and relies on the context inferrer to choose the right parser.
• For the existing structured configuration mode, it relies on the parser collection & rewrite utility to transform and parse the statements under the configured context: value.

Link to tracking Issue: #29017

Testing:

• Just a few unit tests for validation purposes , it's still lacking several test cases

Documentation:

• No documentation changes were made at this point.

[github-actions]

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

[github-actions]

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

[github-actions]

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

[evan-bradley]

Marking this as never-stale since it will help inform us on the approach for #29017 as we implement the actual PRs. This issue is high-priority, so we won't forget about this PR.