feat: global context for logging

[eschutho]

SUMMARY

We have a few examples in the codebase where for logging purposes we need to pass data down to parts of the codebase that have no need to know about this data. It creates very coupled and bloated modules that often are just passing data down without even acting on it. This change proposes the use of a global context dictionary that is used for read-only purposes for logging.

There are three places where we can use this functionality. One is an open PR that I wrote that helps us to log a report execution id to tie together multiple logs to the same report execution.
Another example is passing report header data to an smtp event for logging in a mail server.
And the third use case is to pass dashboard_id and chart_id into the sql mutator for logging.

I have rewritten the first two examples each in one commit in this PR for diffing the implementations for each with a global context. I'll add how the third example (sql mutator) either in this PR or in a subsequent one.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue:
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • Migration is atomic, supports rollback & is backwards-compatible
  • Confirm DB migration upgrade and downgrade tested
  • Runtime estimates and downtime expectations provided
• Introduces new feature or API
• Removes existing feature or API

[john-bodley]

@eschutho out of interest what's the criteria for logging additional context and is there any concern about how much additional data we're passing over the wire? How do we resolve situations where different organizations have different requirements?

[eschutho]

Thanks @john-bodley I'd love to get some early feedback on this idea. As I'm refactoring existing code, I've been targeting that one constraint would be to only store ids in the global context. When logging, the module responsible for logging can fetch the global context id and then any relevant information from the metadata that it needs. The context doesn't need to store or know about all the data that the logger needs, just the minimum requirements.

My main concern is more around the global context getting messy and overused. I don't think there are issues about sending information over a network request, since the context should not be returned in any api responses, but I don't want it to become a dumping ground for passing around any kind of state because that would be an antipattern. Instead, if we limit it to single resource ids, or perhaps a list of ids, I think that could get us where we need for now, and we can reevaluate if other situations arise where we feel we would need this.

[eschutho]

I'm closing this and splitting it into smaller PRs.