Make Telemetry API log record type generic

[raphael-theriault-swi]

📬 Issue #, if available: #977

✍️ Description of changes:

This adds a generic type parameter to LambdaTelemetryRecord for logs to support structured JSON logs. I initially tried to implement the RawValue newtype based solution suggested in #977, but it turns out you can't use RawValue within #[serde(flatten)].

This is a breaking change given it introduces a new generic parameter, but IMO it's better than introducing a whole new set of duplicate types, especially given supporting managed instances may already require breakage soon.

Unlike suggested in #977, this doesn't lock users into either supporting text or JSON logs at compile time, since they can just use an untagged enum:

#[derive(Deserialize)]
#[serde(untagged)]
enum LogRecord {
    Text(String),
    Json(StructuredLogRecord),
}

I also opted against adding a new struct for JSON logs since they don't have a fixed schema, some extension authors might want to use serde_json::Value, some might want a more specialized type.

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[jlizen]

This is a breaking change given it introduces a new generic parameter, but IMO it's better than introducing a whole new set of duplicate types, especially given supporting managed instances may already require breakage soon.

Managed instances will not require semver breaking. We are a long ways off from release 2.x.

With that in mind, do you have any thoughts about a semver-safe way to do it? I guess we just add a new API, deprecate the old, but allow continuing to use old until next release version?

[jlizen]

(Also, thanks for picking this up! This is definitely in an awkward spot right now)

[raphael-theriault-swi]

I'm thinking maybe an opt-in feature to enable the generic might be more elegant ? Then the feature can just be removed when a future 2.x comes out.