feat: add support for custom properties in error tracking

[jonathanlab]

Closes #132

Exceptions now support custom properties. Technically backwards compatible since NewDefaultException can be called w/o properties, but since we drop ExceptionInApiProperties it's a breaking change. Also added slog support.

client.Enqueue(posthog.NewDefaultException(
    time.Now(),
    "user-123",
    "Error title",
    "Description",
    posthog.NewProperties().
        Set("environment", "production").
        Set("retry_count", 3),
))

// Slog
logger := slog.New(posthog.NewSlogCaptureHandler(baseHandler, client,
    posthog.WithPropertiesFn(func(ctx context.Context, r slog.Record) posthog.Properties {
        props := posthog.NewProperties()
        r.Attrs(func(a slog.Attr) bool {
            props.Set(a.Key, a.Value.Any())
            return true
        })
        return props
    }),
))
logger.Error("Payment failed", "payment_id", "pay_123", "amount", 99.99)

[marandaneto]

if we follow semver (Do we here?) this should be a major since it'll break people's apps compilation until they change the type

[jonathanlab]

Seems like in CHANGELOG.md we previously used a minor version for a breaking changes release, so not sure if we're strictly following semver. Happy to bump to 2.0.0 if we want to start being more strict about it.

[orian]

yeah, the versioning in Go got messed up at some point and people often release breaking changes as 1.X change.

[MunifTanjim]

imo, until the sdk reaches feature parity with the other more mature ones (e.g. js sdk), breaking changes are okay without major version bump. The APIs in go sdk still leaves a lot to be desired (compared to the other ones). I'd assume a few other breaking changes like this might be necessary going forward.

[orian]

This is confusing and will lead to errors.
It's know sometimes people abuse variadic arg number in Go, but I think we should just proper properties Properties, that's all.

[orian]

alternatively, add a method to Exception: WithProperties

[jonathanlab]

Great idea, I'll do WithProperties instead.

[MunifTanjim]

Just curious, wouldn't it be better to re-use msg.Properties instead of creating a new one here?

[jonathanlab]

We can't do that unfortunately, because that'd mutate the caller's msg.Properties (preferably no side-effects happen), so we create a new one instead

[vdekrijger]

Minor, but is it worth considering having something like this (shamelessly taken from the unit test) as default behavior?

Suggested change

	return NewProperties()
	props := NewProperties()
	r.Attrs(func(a slog.Attr) bool {
	props.Set(a.Key, a.Value.Any())
	return true
	})
	return props

I figure that most users will likely do something like this as their default behaviour, and if they don't they can override it through WithPropertiesFn.