Separate `RemoteMessage` hierarchy from DSP message classes

[ndr-brt]

Feature Request

Currently the DSP message classes (ContractNegotiationRequestMessage, TransferProcessStartMessage, ...) are subclass of RemoteMessage, but in fact they should not, because they are just representing the payload of a DSP message, not the whole envelope with metadata as protocol, counterPartyAddress, policy and so on.

Why Is the Feature Desired?

make all the classes immutable (at the moment there are some setters that could be avoided with the new design), separate responsibilities.

Who will sponsor this feature?

Please @-mention the committer that will sponsor your feature.

Solution Proposal

My proposal would be to create two new classes:

• DspIngressMessage
• DspEgressMessage
  both extending RemoteMessage, that will contain the metadata plus the message payload class.

The current DSP message classes won't be extending RemoteMessage, maybe a DspMessagePayload marker interface will be introduced

[github-actions]

This issue is stale because it has been open for 14 days with no activity.