feat: Add new keptn version with context propagation in place

[joaopgrassi]

This PR

Introduces a new version of keptn lib with Go context propagation in the methods/functions.

Related Issues

Part of keptn/enhancement-proposals#30 (comment)

Notes

The need for this comes with our intention of adding OpenTelemetry instrumentation to Keptn. The way context propagation works in OpenTelemetry for Go is via the context.Context object. It is used to pass along cross-cutting concerns, such as cancellation and now, the tracecontext information.

Since changing the existing methods will incur a breaking API change, a new version of the package is needed.

[sonarqubecloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

No Coverage information
18.0% Duplication

[joaopgrassi]

@bacherfl @warber what you think about this? Should we always set cloudevents.WithEncodingStructured(ctx) in here, as it was done before in SendEvent? This will make transitioning to this version easier.

I get that by doing so we lose flexibility in case we want to use binary encoding later. But is that even the case? I tried checking if such encoding config is already present, but as my comment says the key added to ctx is not exported in cloudevents.

[joaopgrassi]

We have to also think what to do with the code in pkg/api/utils. There's several methods there that performs http requests such as creating a project.

In the POC instrumentation PR , all the HTTP clients used inside utils, are instrumented with OpenTelemetry. This means that all requests made from them will generate a span automatically.

The issue though is: if those requests are part of a larger transaction, then the spans produced by them will be not part of the trace.

For ex: If the DeleteProject is called due to another operation elsewhere, the call to it here will generate a span "outside" of the trace that originated it.

It might be the case that we are not interested in the spans generated by these files here, but that's something I really cannot tell. If that is the case, then we don't even need to add auto-instrumentation to the HTTP clients used inside utils.

[joaopgrassi]

Going to favor this in favor of adding the context inside the Keptn struct, as one of approaches described in the articles: https://go.dev/blog/context-and-structs, https://go.dev/blog/module-compatibility and this GH issue: golang/go#22602. A follow up PR for this version is coming up next.