feat(seer-activity): Implement activity action registry

[leeandher]

The mapping is a bit messy but it goes like this:

ActionRegistry
> GroupTypeRegistry 
>> if (event is Activity) 
>>> if (activity is not Metric Resolution)
>>>> ActivityHandlerRegistry
>>>>> actual handlers (in this case, NotificationPlatformActivityHandler)

This is necessary since we don't want to modify the pathway for Metric Issue resolution just yet, but if we get those status changes migrated the activity registry, we can probably move all of this out of GroupActivityRegistry and just modify the ActionRegistry members directly, maybe even split out ActionInvocation into two concrete types 🤷

But for now, this new registry will let us create a pathway just for our new activity triggers. Added an option for safety, but it'll be removed when released.

[linear-code]

ISWF-2728

[cursor]

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

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

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

[Christinarlong]

This is giving, notificationservice v2 lmao

[Christinarlong]

I think so far this
Activity -> ActivityHandlerRegistry -> get handler based on ActionType -> Handler Invoke makes sense.

Some half baked thoughts

• This means actiontype is 1:1 with a handler, which is kinda rigid. Though, I'm not sure if we'd ever need some escape hatch for like email to throw to another handler.
• But also registering everything that NP supports means that, all compatible activities will need to be supported. I wonder if it'd be better to seperate it out to like - EmailNotificationPlatformActivityHandler instead of 1 big np handler.
• Or thoughts on instead going from activity -> handler (like key on activitytype vs actiontype)

[leeandher]

thanks for the thoughts! I went back and forth on this stuff, but heres where im at:

actiontype is 1:1 with a handler, which is kinda rigid

• I think I'm okay with this since at this stage the action is the thing we need to specifically be implementing. it also means that the total amount of handlers were expecting if everything is built out is less than a dozen (e.g. pagerduty, sentry apps, github tickets, messaging integrations etc)

I wonder if it'd be better to seperate it out to like - EmailNotificationPlatformActivityHandler instead of 1 big np handler

• also fair! but for now, im going for the most coverage possible off the start. It's straightforward enough to separate out the handlers after by registering the EMAIL key to a new handler if we need, but we can take advantage of the defaults from notification platform this way 🙏

like key on activitytype vs actiontype

• I thought about this too, the problem ends up being that we still need to have a key on actiontype at some point, since the same code for creating a gh ticket cant send a slack message. It just makes the amount of handlers much larger too, since for each activity (~35), there are separate actions we need (~10), so like 350 registrants that way. Even if we abstract the actions, that's still 35 registrants.

I figured itd be more likely that the action code would be shared, and added the compatible_activity_types to have some safety, so we end up with ~10 registrants, and even less if we keep this big notif platform handler

[Christinarlong]

Makes sense, I'm still a bit worried about the scope of testing pt. 2 but as you said it's not that much work to separate out and I think the invoke implementation will also help inform

[Christinarlong]

Makes sense, I'm still a bit worried about the scope of testing pt. 2 but as you said it's not that much work to separate out and I think the invoke implementation will also help inform