RUMM-478 Skip sanitization of log attributes created by Tracing

[ncreated]

What and why?

📦 The SDK performs sanitization for Log attributes created by the user. This includes list of reserved attributes, that get removed when given by the user. This PR adds dd.trace_id and dd.span_id to that list.

How?

The reason why it was not done in #117 is that this includes additional refactoring. It is the subject of this PR.

The LogOutput was not differentiating if the attribute comes from the user, or is set internally by the LoggingForTracingAdapter:

internal protocol LogOutput {
    func writeLogWith(level: LogLevel, message: String, date: Date, attributes: [String: Encodable], tags: Set<String>)
}

This is now changed by introducing LogAttributes type:

internal struct LogAttributes {
    /// Log attributes received from the user. They are subject for sanitization.
    let userAttributes: [String: Encodable]
    /// Log attributes added internally by the SDK. They are not a subject for sanitization.
    let internalAttributes: [String: Encodable]?
}

internal protocol LogOutput {
    func writeLogWith(level: LogLevel, message: String, date: Date, attributes: LogAttributes, tags: Set<String>)
}

The .userAttributes are considered and .internalAttributes are skipped for sanitization.

Benchmarks

I tested it with benchmarks - no impact, but in theory it should be even more performant, as more logic is now moved to LogEncoder, which runs on the background thread.

I also include benchmark baselines for my iPhone X deleted in #63, as a reference point for future changes.

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

[buranmert]

✅

as an alternative idea: we could give Keys more context

struct Key {
  enum Kind {
    case user
    case sdk
  }
  let kind: Kind // default .user
  let name: String
}

that way we can handle more special cases with more enum cases instead of more LogAttributes properties

[ncreated]

as an alternative idea: we could give Keys more context
that way we can handle more special cases with more enum cases instead of more LogAttributes properties

Maybe, if we have way more Log attribute kinds than "user defined" and "internal", but I don't see such use case right now nor in the near future. As .kind check will require additional processing and more complex hash function, this should be deeply considered.

[buranmert]

i didn't mention hashing to keep it short but it was the actual gist of it:

struct Key: Hashable {
  let name: String
  var hash: Int { name.hash }
}

this ensures that there cannot be duplicate attributes in a dictionary
and we don't have to be careful with the order of operations (eg: first userAttr and then internalAttr in LogEncoder)
only required change would be if case .sdk = key.kind { skip(key) } in LogSanitizer

i'm leaving this comment here only not to forget later :)