Allow ordering between broadcasts and private messages

[gabriel-indik]

In certain applications business objects contain a combination of public and private information. Public information is shared across all members using broadcasts and private information is then sent to selected members using private messaging. From an application development point of view, it would be convenient if the ordering between the broadcasts and the private (blockchain pinned) messages could be guaranteed.

[peterbroadhurst]

There's another related case, which is between private groups:

1. Parties A&B have a group x, and do transactions 1,2,3
2. Party C needs to be included, so a new group y is created with A,B & C
3. Parties A&B share some state history from x to y
4. The business transaction continues on y
5. ... maybe A&B want to continue after C is finished with their bit, using data C can't see - so transaction continues on x

[peterbroadhurst]

A generic feature that would support this would be:

• Add a new optional header.after (or similar) field on Message that takes a message ID directly
• The field would only be supported on private messages (not needed for broadcast, and potentially problematic there)
• The message can be public or private, and on any context
• The aggregator would check for this message being confirmed, and not confirm the message that refers to it
• Hard bit: The aggregator would rewind when the message is later confirmed