[pkg/ottl] Update ExprFunc and boolExpressionEvaluator to return an error

[TylerHelmuth]

Description:
Changes ExprFunc,Get and Set. This allows errors from contexts to be propagated upward to a place where they can be better handled.

This PR only adds the capability to return errors. It does not update any error handling.

Link to tracking Issue:
Related to #13690

Testing:
Updated unit tests

[MikeGoldsmith]

Change overall looks good but there's lots of places we're ignoring the returned error, both in test and functional components (I've tagged some but there were a lot). We should check the error for nils, as the structure for checking shouldn't change.

[TylerHelmuth]

@MikeGoldsmith I'll update the tests to be more rigorous and the functions to return their errors, but the calling function, Execute will continue to swallow errors for now.

[bogdandrutu]

If you do this change, I would suggest to change ExprFunc to an interface Expr. It is more flexible for the future, you can still have the ExprFunc implementing the interface.

type Expr[K any] interface {
  func Eval(ctx context.Context, tCtx K) (any, error)
}

type ExprFunc[K any] func(ctx context.Context, tCtx K) (interface{}, error)

func (f ExprFunc[K]) Eval(ctx context.Context, tCtx K) {
  return f(ctx, tCtx)
}

This way in the future we can have optional interfaces that these instances can implement and based on that can extend the capabilities. With the current type ExprFunc we are locked in this, since we cannot add other private members and does not make too much sense to add extra funcs on it since cannot be configured in any way.

Another option that allows extension is to have a struct:

type Expr[K any] struct {
  EvalFunc[K]
}

func (e Expr[K]) Eval(ctx context.Context, tCtx K) {
  return e.EvalFunc(ctx, tCtx)
}

type EvalFunc[K any] func(ctx context.Context, tCtx K) (interface{}, error)

[TylerHelmuth]

If you do this change, I would suggest to change ExprFunc to an interface Expr

@bogdandrutu this request is being tracked via #14713, do you want to do that as part of this PR or can it be its own?

[bogdandrutu]

@TylerHelmuth I think at least we should also add "context.Context" to the func :) since we touch that signature. We can do a separate one for the interface/struct.

[TylerHelmuth]

@bogdandrutu we don't have a use case yet for passing context.Context, whereas this PR will enable us to return an error from any ottl context that attempts to use the MetricType setter. Can we hold off on that change until we have a concrete use case, or at least via its own PR?

[bogdandrutu]

@bogdandrutu we don't have a use case yet for passing context.Context

1. It is best practice to pass Context. So you can for example when log something do correlation with tracing.
2. We can extract things from "Client" part of the Context. See https://github.com/open-telemetry/opentelemetry-collector/tree/main/client

In other words we should pass context almost every time in golang :)

We can do a separate PR for sure, but it should be done.

[TylerHelmuth]

In other words we should pass context almost every time in golang

@bogdandrutu is the claim that any function that accepts context.Context in golang should also pass context.Context to every function its calls?

[bogdandrutu]

@bogdandrutu is the claim that any function that accepts context.Context in golang should also pass context.Context to every function its calls?

Not "every". But in 90% of the cases yes :)

[TylerHelmuth]

@bogdandrutu ok, I will implement that in a later PR

[TylerHelmuth]

@evan-bradley @kentquirk please review.