impr(sentry apps): Add Duration, Resource ids, Request id to the dashboard

[Christinarlong]

Adds 4 new fields to the request buffer

    request_id: NotRequired[str | None]  # Maps to requestId header on webhook
    subject_id: NotRequired[str | None]  # ID for the resource denoted in subjectType
    subject_type: NotRequired[str | None]  # Resource type (e.g. Group, Event, Seer Run)
    duration_ms: NotRequired[int | None]  # Time taken to send the request

For the subject/resource fields, there's a mapping we do that first checks if the specific event_type (issue.created, seer.autofix_run_started etc.) has a resource override else we have default resources(e.g Event, Group etc.) for each of the webhook resources. Currently the mapping from webhook resource -> subject is 1:1 but I think that makes sense for most cases since webhooks are generally some model being serialized.

This PR also breaks out ConnectionError to be its own handling (kinda), mainly jsut add a new fake status code so we can tell in the UI

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit dbda0ff. Configure here.}

[mrduncan]

Should we just not support this to spare ourselves cleanup work later?

[Christinarlong]

The current discrepancy is that the the webhooks still use a payload body that references the legacy models and doesn't have any identifiers to the new models 😭 . I think we should have a top level resource/subject identifier for all the resources so I think we should start with this.

The real shim/fix would be updating the metric alert payload to have detector or smthn and just using that here.

[mrduncan]

We could also potentially record the duration here and above on connection errors as the difference between just before _send_webhook_request and now - not sure if that's meaningful but it would mean that we always have a duration on all requests (after 30d)

[Christinarlong]

I would prefer we have a p. certain source of truth of the response object for the duration (i.e how long did the req itself take versus anything surrounding since that's what the timeout is working against. Other custom timers Imo would get confusing and I think for connection errors idt duration would be too useful since it's not a latency type error.