Ensure that log attributes of Object type are stringified

[lcian]

📜 Description

Ensures we stringify objects properly and adds attributes of other types to the de/serialization test.

#skip-changelog

[lcian]

Need to do this otherwise the object could get serialized as JSON and not as a String.
Example:

public class Point {
  public int x;
  public int y;

  public Point(int x, int y) {
    this.x = x;
    this.y = y;
  }

  @Override
  public String toString() {
    return "Point(" + x + ", " + y + ")";
  }
}

Send it as an attribute/format string param and it serializes as

"sentry.message.parameter.0":{"type":"string","value":{"x":10,"y":20}}}}]}

So with the JSON representation, which will not get ingested. We need to call toString on it.

It will appear in the formatted message though as String.format will call toString, so that's another reason why I think it's correct to call toString on it.

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	438.62 ms	448.16 ms	9.54 ms
Size	1.58 MiB	2.08 MiB	510.55 KiB

Baseline results on branch: feat/logs-attributes-in-api

Startup times

Revision	Plain	With Sentry	Diff
878e381	402.20 ms	417.65 ms	15.45 ms
93da41e	429.70 ms	484.57 ms	54.87 ms

App size

Revision	Plain	With Sentry	Diff
878e381	1.58 MiB	2.08 MiB	510.51 KiB
93da41e	1.58 MiB	2.08 MiB	510.52 KiB

Previous results on branch: lcian/fix/attributes-de-serialization

Startup times

Revision	Plain	With Sentry	Diff
aff133e	438.25 ms	479.80 ms	41.55 ms

App size

Revision	Plain	With Sentry	Diff
aff133e	1.58 MiB	2.08 MiB	510.54 KiB

[romtsn]

so we don't have a dedicated object type? I think this looks a bit ugly from an API standpoint to specify a string type and then pass an object in 😬

I think our UI supports building trees based on the dot-convention, so how I'd image it looking in pseudocode:

// we get this as an input
"point" to SentryLogEventAttributeValue("object", Point(20,30))

// we now know it's an object type so we should dismember it via reflection
val parentKey = "point"
for (field in getDeclaredFields) {
  // do this recursively for nested objects
  serialize(parentKey + "." + field.name to SentryLogEventAttributeValue(field.type, field.value))
}

Do you think that would be feasible? The object type is only on the SDK level but does not get passed to our backend. Kind of like our JsonObjectSerializer does via reflection.

[lcian]

I was wondering how objects were actually serialized as JSON :)

So, for what it's worth this SentryLogEventAttributeValue is not really meant to be used directly by users, I think it should be marked ApiStatus.Internal.
We expect the user to call log(attributes, ...) where attributes is a Map<String, Object>.
So we could have an object type that we use internally, also I think we should really use an enum for the type and not a string.

Anyway, I think yours is a cool idea, I just don't know if that's what a user would expect to see there, or if they would rather see value.toString() as the attribute value. In the Java world I would say people would expect value.toString(), what do you think?
Let me also check internally what we expect from an end product prespective because this could apply to many other platforms.