RUMM-1090 Make LogEvent and UserInfo public

[maxep]

What and why?

Make LogEvent and UserInfo public.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference

[ncreated]

This UserInfo is part of Datadog/Core. Both Tracing and RUM use their own representation of user info:

• SpanEvent.UserInfo for Tracing - it has slightly different signature ([String: String] for extra info),
• RUMUser for RUM -it is auto-generated model from RUM schema.

I'm in between:

• 1/ exposing this Core.UserInfo only for LogEvent,
• 2/ creating LogEvent.UserInfo and having mapper.

Going with the 2nd approach would make the architecture aligned with other products for UserInfo, but would require duplicating its definition. I personally prefer small duplication over bad abstraction and that might be the case given that we're planning to modularize our SDK soon into separate libraries (Tracing / RUM / Logging).

On the other hand, same thing applies to NetworkConnectionInfo and CarrierInfo which are both public and used from SpanEvent and (now) LogEvent, but not RUMEvent (RUM maps both into a single RUMConnectivity value). That would need to be tackled somehow later in mentioned modularization.

What's your take on that?

[maxep]

I had the exact same thought process, I started by creating an inner LogEvent.UserInfo but then I noticed both NetworkConnectionInfo and CarrierInfo were shared.

For modularization prospect, using contained model definition per feature and use abstractions for shared data would be a good approach IMHO. Using an inner UserInfo would be a step in that direction and facilitate the transition. I will do the change!

[ncreated]

There are two motivations behind the scrubbing API, uniformly met in Tracing and RUM scrubbing:

• 1/ the user can see all user-controlled values that will be sent to Datadog,
• 2/ the user can redact some of these values (we decide what is mutable and what is not).

Here, this internal error does clearly hide some information (1), because it is serialized into 3 distinct fields:

// Encode log.error properties
if let someError = log.error {
    try container.encode(someError.type, forKey: .errorKind)
    try container.encode(someError.message, forKey: .errorMessage)
    try container.encode(someError.stack, forKey: .errorStack)
}

How about defining these 3 values as explicit properties on LogEvent:

public let error: LogEvent.Error?

public struct LogEvent.Error {
   public let kind: String?
   public let message: String?
   public let stack: String?
}

and extracting their values from DDError before creating the LogEvent (so in LogEventBuilder)? Then, we can decide (2) if any of these values should be mutable var - in RUM we allow redaction of error.message and error.stack but not error.type. WDYT?

[ncreated]

🎯