feat: add DomainEvent activity

[cfgiugliano]

This adds the DomainEvent activity as proposed in #5583

---

This change is 

[cfgiugliano]

@dotnet-policy-service agree

[sfmskywalker]

Would it make sense to use INotificationSender instead of IWebhookDispatcher?

[cfgiugliano]

This was added to provide feature parity with the RunTask and I thought this was just a default notification handler, but what would be the reason for this additional indirection of a notification publishing another notification?

[sfmskywalker]

I was more thinking that we want to be able to publish domain events, which are "lower-level" than webhook events. Ergo, it doesn't make sense to me to use a service called "webhook dispatcher" when it has nothing to do with webhooks. For that reason, I'm thinking that using INoticationSender is more suitable. The webhook dispatcher uses this too under the hood. Alternatively, we could consider adding a new service called e.g. IDomainEventDispatcher (which would probably still use INotificationSender, just like IWebhookDispatcher).

[cfgiugliano]

But the activity execution is already publishing a the domain event as notification using INotificationSender (this could be chanced to consume a IDomainEventDispatcher, yes) but the current handler is just a default implementation of the notification handler like for RunTask. If required, it is still possible to implement a custom handler and handle the domain event with custom logic

[cfgiugliano]

I've added a IDomainEventDispatcher with both a background and synchronous implementation, and exposed a factory in WorfklowsRuntimeFeature just like for the ITaskDispatcher, then updated the handler under webhook.

[sfmskywalker]

Hi @cfgiugliano, thank you for all the nice work!

I need more time to go through the PR, but I'll offer som initial thoughts.

• I am not a fan of having a separate DomainEvent and an Event, because Event serves the same purpose and having two models that are conceptually the same but have a different effect does not seem all to clean.
• Instead, I would explore the possibility of refactoring the PublishEvent activity to use the mediator and publish a notification.
• One handler would then attempt to resume any event bookmarks
• Another handler, living in the Webhooks module, would deliver the event to any & all sinks by invoking the webhook dispatcher using the event name as the webhook name.

I think this would reduce some redundancy while still being able to deliver events to webhook sinks.
Alternatively, I would also be open to the idea of having a "webhooks only" model, where we would have the following things:

• a PublishWebhookEvent activity
• a WebhookEvent model carrying the webhook event name + payload.

A potential benefits of this specialized API might be:

• Focused problem domain
• No performance degradation, like with attempting to publish Events as Webhooks and resuming Event activities, which add overhead even if there are no workflows waiting for this event and there are no webhooks listening. That being said, this of course would largely depend on how "smart" the notification handlers are implemented by minimizing overhead.

And perhaps we could have both. It's nice to have options.