Epic: Versioning of Message Payloads

[gsteinacker]

Currently, it is not possible to migrate the format of message payloads beside of adding optional properties to the json structure.
The aim of this issue is to add the capability to support different payload versions in a single channel.
There are at least two possibilities to do so:

A) Determining the payload version by introspecting the message payload itself or
B) Determining the payload version by supporting version information as meta-data in the message header.

Possibility A is easier to implement, but B has a few advantages:

• It is easier and less time consuming to check for a message header than parsing payloads, especially if the payload is large.
• Using meta-data instead of parsing the payload is the cleaner solution, making versions more explicit and helping developers to understand the behavior of the messaging system.
• If it is possible to introduce message headers for a version (without losing header information during compaction), it is also easy to introduce further header information such as timestamps or correlation identifiers.

Especially because of the latter point, this epic is following solution B by:

• [Issue Support custom headers #25] Adding the feature to add custom attributes to the Header
• [Issue Introduce Snapshot MessageStore that stores messages including headers #20] Introduce a new Snapshot MessageStore implementation that is storing messages including custom headers
• [Issue Support for message headers being transferred from senders to receivers #11] Adding end-to-end transportation of custom headers from senders to receivers
• [Issue Support versioning of message payloads in consumer annotations #24] Adding features to EventSourceConsumer, MessageQueueConsumer and MessageLogConsumer annotations to select messages based on versions or - more generally - header information