Address content-type compatibility between messages generated by different versions of SCSt apps

Due to the recent content-type negotiation improvements we unintentionally introduced compatibility issue where pre-2.0 consumers may not be able to properly negotiate the content type of the message generated by 2.0+ producers. This is due to the fact that pre-2.0 producers and consumers were relying on the original-content-type header which was removed in 2.0. Another change that was introduced as part of this effort deals with registering additional flag (spring.cloud.stream.bindings.input.legacyContentTypeHeaderEnabled) and interceptor (LegacyContentTypeHeaderInterceptor) to allow 2.0+ consumers to successfully process pre-2.0 messages. This issue is that it makes consumer statically aware of the producer and its version and could result in more issues if such consumer receives messages from the producers of different versions.

Proposal:

1. 2.0 producer should re-introduce the original-content-type header. While this header will be ignored by 2.0 consumers it will be used by pre-2.0 consumers as before. It should also generate one additional header such as version (e.g., version=2.x). This additional header will be used by 2.0+ consumers to ignore the re-introduced original-content-type header (more details below).
2. 2.0 consumer should have a mechanism (may be through the already existing LegacyContentTypeHeaderInterceptor) to check for the version header before checking for the existence of the original-content-type header. If ‘version’ header is pre-2.0 or is not present (which is what’s going to be in the case of pre-2.0 producers) then we know it’s a legacy message and content-type negotiation should be done using the original-content-type header, otherwise such header will be ignored. Basically the version header will play the same role as newly introduced spring.cloud.stream.bindings.input.legacyContentTypeHeaderEnabled flag, but it will come as part of the message instead of static configuration of the consumer. Further more, making it a version instead of a boolean will give us more flexibility in the future when it comes to similar issues especially if we decide to drop support for certain version of messages.

[sobychacko]

Since we only support Kafka 0.11 and up in 2.0, how about we say that in the case of Kafka based apps, 1.3 is backward/forward compatible with 2.0, as long as it uses the latest Kafka broker (since 1.3 can work with 0.11 by ignoring native headers and transactions). That way, we don’t have to bring support for all the 0.10.x versions of Kafka in 2.0 which is going to be very challenging.

[artembilan]

Reopen. Closed automatically by merge relevant PR