Improve `DomainException`

[Lucas Trzesniewski]

• Add a bool ShouldPublishError property to DomainException, to make it possible to respond with an error code or message, but also to publish the exception as a real error.
• Maybe we should also create an exception with a better name than DomainException, and inherit DomainException from it. Do you have good ideas?
  Here are some proposals: MessageHandlerException, MessageDispatchException, MessageProcessingException, MessageExecutionException

[Lowell Manners]

An alternative could be to add a 'level' to DomainExceptions, then configure somewhere globally what level of domain exceptions are published.

This approach might be more useful for debugging, though it's a bit more complicated (not sure if it's better overall).

[Olivier Coanet]

I like MessageProcessingException because it is associated with MessageProcessingFailed.
In my view DomainException is a legacy term from the "ServiceBus" port and it should be marked as obsolete.

[Lucas Trzesniewski]

MessageProcessingException seems to be winning the vote internally.

I'm not sure we should mark DomainException as obsolete right away, as that would break lots of our code (since we activated warnings as errors everywhere). But we could always search & replace all of them easily.

@lmanners I wanted the message handler itself to be able to tell if a given exception should be published as an error. I had a case where I wanted to publish an error for the first message that gets rate limited, but not for the subsequent ones. I prefer having a simple bool property over some configurable mechanism for this. 😉

[Lucas Trzesniewski]

I added a simple MessageProcessingException. I like the design with an init ErrorCode property, feel free to comment the API.