[pkg/ottl] Change grammar to support expressing statements context via path names

[edmocosta]

Description:

This PR is part of the #29017, and introduces the necessary OTTL Grammar/Parser changes to make it possible for statements express their context via path names.

This first iteration changes the grammar to parse 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"}]}.

To make it non-breaking to all components during the transition time and development, this PR also changes the ottl.Parser[k].newPath function to, by default, fall this new behavior back to the previous one, using the grammar's parsed Context value as the first path segment (Fields[0]).

Two new Parser[K] options were added, WithPathContextNames and WithPathContextNameValidation, The first option will be used to enable the statements context support, parsing the first path segment as Context when the value maches any configured context names, or falling it back otherwise. The second option will be used to enable the validation and turning off the backward compatible mode, raising an error when paths have no context prefix, or when it's invalid.

For more details, please check the #29017 discussion out.

Link to tracking Issue: #29017

Testing:

• Unit tests

Documentation:

• No documentation changes were made at this point.

[TylerHelmuth]

@edmocosta I like the way this is looking.

For big refactors like this is gonna end up being we typically create a draft PR with all the changes implemented as if we were going to merge in a breaking change. Can you create a draft PR like that for this work? I'm interested to see the final picture for what we're trying to achieve before we start merging things. Don't worry about unit tests, I just want to see who the API and implementation shakes out.

[TylerHelmuth]

We can remove this else.

[TylerHelmuth]

We can remove this else.

[edmocosta]

@edmocosta I like the way this is looking.

For big refactors like this is gonna end up being we typically create a draft PR with all the changes implemented as if we were going to merge in a breaking change. Can you create a draft PR like that for this work? I'm interested to see the final picture for what we're trying to achieve before we start merging things. Don't worry about unit tests, I just want to see who the API and implementation shakes out.

Sure thing! I'll create a draft PR with all the pieces together soon! Thanks @TylerHelmuth!

[edmocosta]

Hi @TylerHelmuth! here's the draft PR: #35050
It includes all the changes we've been discussing. It certainly needs more work/discussions, including extra changes, adding tests, docs, code style, etc. It's a working draft implementation, so If you want you can try it out locally.

[TylerHelmuth]

@edmocosta thanks for quickly writing up that draft. There is definitely a lot of complexity we're adding with this change, but I believe the portability and readability of:

trace_statements:
  - set(span.status.code, 1) where span.attributes["http.path"] == "/health"

is really nice. Take a look at the remaining comments and then we can get this merged and move on to the next step.

[edmocosta]

@TylerHelmuth, I've addressed the suggestions, plus two nitpicks that I changed on the draft PR:

• Changed the pathContextNames type from map[string]bool to map[string]struct{}
• Added the possibly word on the error message here. IMO, It's clear specially when the statement is invalid and only contains ambiguous context name, for example set(resource.attributes["foo"], invalid.context)