fix(api-server): fix trace/span ID processing in logs

[bartsmykla]

Problem:

Currently, processing trace/span IDs before logging them (e.g., converting them to Datadog format) requires calling NewSpanLogValuesProcessorContext with the runtime.Extensions() context. However, this context isn't always available, particularly when handling errors in REST endpoint handlers through AddFieldsFromCtx. This inconsistency leads to the processing function being ignored.

Proposed Solutions:

• Pass runtime.Extensions() Context to HandleError: While effective, this approach adds significant boilerplate code and requires disabling the contextcheck linter in multiple locations (see PR chore(api-server): pass extensions context to rest endpoints #10094).

• Leverage slog's Contextual Logging (ref: rework AddFieldsFromCtx to be less combersome #8216): This approach offers cleaner code but requires significant changes to our logging infrastructure (ones which I immediately faced when tried to do a quick POC):

  • slog lacks the concept of logger names, necessitating a custom slog.Handler for maintaining desired log structure.
  • We'd need to abandon using globally configured/named loggers or potentially introduce deferred logger initialization logic for slog.

Current Solution (For This PR):

To address the issue without a major logging overhaul, this PR proposes a simpler solution:

• Pass the logger instance through the context when constructing ApiServer.
• Restore the logger from the context in HandleError function.

This approach, while not ideal due to the passing logger via context, effectively resolves the problem without introducing complex logging changes.

Additional changes:

I adjusted the signature of NewApiServer function to accept the whole runtime.Runtime, which reduced significantly the amount of necessary arguments, which were attained from the runtime.Runtime. It makes contextcheck linter happy as we don't have to pass runtime.Extensions() context as an argument, which linter would flag as passed and not used, without realising it's not the regular context.

Checklist prior to review

• Link to relevant issue as well as docs and UI issues
  • No relevant issues
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as a image registry) and it will work on Windows, system specific functions like syscall.Mkfifo have equivalent implementation on the other OS
  • It won't
• Tests (Unit test, E2E tests, manual test on universal and k8s)
  • Manually tested by running local OTEL collector and then manually triggering handlers to return error with ant without span logging processors
  • Don't forget ci/ labels to run additional/fewer tests
• Do you need to update UPGRADE.md?
  • There is no need
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label)
  • There is no need I think 🤔

[slonka]

I'm approving this but I might be biased, I'll let someone else also review this