[pkg/ottl] Basic math capabilities

[TylerHelmuth]

Description:
Adds basic math operations to the grammar. The grammar now supports +, -, *, and / for int64 and float64, as well as invocations and paths that return ints and floats. More types (strings, bytes, etc), could be supported in the future.

Since paths and invocations are supported, calculation of the expressions has to be done during data processing instead of startup. This means that Expressions are always captured as Getters, and in order for a function to support an Expression it must use a Getter. In the future I'd like to improve this by creating Typed Getters, but I believe that should be saved for a future PR.

To support both Expressions and literal values in the value struct I needed to reorganize the grammar so that it can differentiate between an Invocation/Path/Float/Int that is the start of an expression and an Invocation/Path/Float/Int that is "standalone". This is achieved by using the grammar library's negative lookahead feature. In order for negative lookahead to work correctly in the value's OR clause, it needed to appear only once. As a result, all grammar types that are supported by Expression were moved into a sub struct. This caused a lot of changes in the PR, but I do believe is necessary. See alecthomas/participle#279 for some details on how I landed at this conclusion.

Link to tracking Issue:
Closes #15675

Testing:
Added new unit tests

Documentation:
Update ottl grammar doc

[evan-bradley]

Looks mostly good to me, I agree with your conclusion on the grammar changes based on what I've read. I will take a more in-depth look at the grammar on Monday.

One question I have is around the operations we want to support: do we expect to only have the four in this PR, or will we want more in the future (exponentiation, bitwise operations, etc.)? As it is right now, setting precedence for additional operations would cause the parsed expression to have a pretty deep structure.

[TylerHelmuth]

will we want more in the future

@evan-bradley good question. I think we could expect to add those once there is a use case for them. Unfortunately the more operations we add the more precedence we have to handle and the deeper the expression structure will go. I don't think there is a good way to handle this as the Term/Factor/Value concept is really the best way to do precedence.

[evan-bradley]

Looks good to me. After taking a second look, I agree with your conclusions about the grammar.

[kentquirk]

I have raised a couple of issues, but I do think they could be fixed here or saved for another day. In general this looks great, so in the interests of keeping things moving I'd be fine with merging this.

[kentquirk]

ok, this opens up a small can of worms. What happens if inf and NaN come through the pipeline? Do we support them as constants in ottl? Should we?

I can definitely imagine somebody wanting something like drop() where attributes["math_field"] == NaN

[TylerHelmuth]

Ya this was an outcome of testing I wasn't really expecting. I think +Inf isn't really a concern, but NaN will be useful once we can get in those situations. I think with the operations we've defined we will always avoid NaN tho.