WIP: Introduce experimental JSON logging

[dominikschubert]

Motivation

We've had a few requests in the past for outputting our logs in a structured format. We've been experimenting in the past but would like to push forward with the idea now. This will be in an experimental stage for some time now and will mostly be used internally before going into public preview and ideally GA release with 4.0 🤞

Changes

• Logs can now also be streamed to a file in JSON format. This is done in a quite naive way right now, we simply take the current log records, and translate it into a JSON dict which then ends up being streamed as newline-delimited JSON where each line corresponds to one log entry.
• The current CLI output is generally not affected by this (except by the addition of the raw request logger)

What's left to do:

• Clean up the code from the initial spike
• Make this opt-in
• Make log sink configurable
• Map keys extracted from the LogRecord to more suitable names
• Investigate the DEBUG-related code we had to comment out for the aws request/response logging

There will also be some follow ups such as:

• Add an internal endpoint to stream logs from (e.g. via websocket)
• Introduce a proper structured logging strategy and rework log levels
• ... lots more to come in the next few months

[dominikschubert]

Suggested change

[dominikschubert]

Suggested change

# TODO: add logger that initializes a request "trace"

[github-actions]

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 38m 49s ⏱️ + 2m 16s
2 941 tests ±0  2 631 ✅  - 9  303 💤 +2  7 ❌ +7 
2 943 runs  ±0  2 631 ✅  - 9  305 💤 +2  7 ❌ +7 

For more details on these failures, see this check.

Results for commit f19f45c. ± Comparison against base commit 3c4c463.

This pull request skips 2 tests.

tests.aws.services.s3.test_s3.TestS3PresignedPost ‑ test_post_object_with_files
tests.aws.services.s3.test_s3.TestS3PresignedPost ‑ test_s3_presigned_post_success_action_status_201_response

[joe4dev]

request_id propagation is gonna be crucial for proper grouping and is going to require quite some manual work within service-specific loggers. Other fields can then be inferred based on the request_id because some other fields won't be available at different stages (e.g., service, region, and operation won't be available before parsing an HTTP request into an AWS request; response-related fields such as status code obviously won't be available before handling the request)