feat: use scoped message handlers via pumps/routers

[stijnmoreels]

Enhances the current message handler registration by scoping any message handler registrations to a pump or router. This means that message handlers registered for another pump/router cannot be used during message routing.

This is a follow-up on the background jobs issue: arcus-azure/arcus.backgroundjobs#200

The cool 😎 thing about this enhancement, is that it does not changes anything for single-message pump/router registrations; but changes the way we work with multiple pumps (which is the case when background jobs are involved).

Closes #395

[netlify]

✅ Deploy Preview for arcus-messaging canceled.

Name	Link
🔨 Latest commit	3a0881b
🔍 Latest deploy log	https://app.netlify.com/sites/arcus-messaging/deploys/64b8e1cf5d5fb6000887c24c

[stijnmoreels]

/azp run CI - Arcus.Messaging

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fgheysels]

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

[stijnmoreels]

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

In situations where you have two different message pumps/routers, the message handlers were previously shared among them. This PR makes sure that each set of message handlers is scoped to the pump/router; meaning that a message handler with the same message type will not 'wrongly' process a message that was meant for another pump/router.
This is especially the case with background jobs, where you process 'events'; and pumps have the same event/message type to process.

[fgheysels]

This means that message handlers registered for another pump/router cannot be used during message routing.

What do you mean exactly ?

In situations where you have two different message pumps/routers, the message handlers were previously shared among them. This PR makes sure that each set of message handlers is scoped to the pump/router; meaning that a message handler with the same message type will not 'wrongly' process a message that was meant for another pump/router. This is especially the case with background jobs, where you process 'events'; and pumps have the same event/message type to process.

Ok thanks. But I would assume that this is something that could not ever happen, as the message handler is registered with a message-pump anyway ?

[stijnmoreels]

Ok thanks. But I would assume that this is something that could not ever happen, as the message handler is registered with a message-pump anyway ?

It seems that we do due to the code syntax, but behind the scenes they are all registered in the same dependency container.
I succeeded in reproducing it by registering our two background jobs (auto-update secret in cache, auto-restart message pump), as they are both registered on 'secret new version created' events on Key Vault.
This PR makes sure that your assumption that the code syntax proposes is reality behind the scenes.