Add charset to headers

[ramonsmits]

Looking at our content type header it does not specify the character set used.

It is fairly common to include the character set. This is useful for native integration scenarios.

Instead of writing the value text/xml we would write text/xml; charset=utf8 or any other character set a serializer would use. This aligns with #3318 as this would be a breaking change. Receivers should support the fact that additional arguments COULD be specified.

We could also use an additional header value to specify the character encoding which would be non breaking or actually use the same header key value as the HTTP specification, 'Content-Type' and obsolete NServiceBus.ContentType.

This is forked from issue #3050 which is closed.

[andreasohlund]

👍 For a new header to avoid a breaking change

[mikeminutillo]

Adding a new header would increase the message overhead and changing the existing one would require ensuring that all downstream serializers (as well as ServiceControl, ServicePulse, and ServiceInsight) are ready to understand and parse this new format.

[mauroservienti]

This would also improve the native integration scenario where the serializer must know the encoding when receiving from non-NServiceBus senders.

[ramonsmits]

changing the existing one would require ensuring that all downstream serializers (as well as ServiceControl, ServicePulse, and ServiceInsight) are ready to understand and parse this new format.

but... could also break backwards compatibility with Core versions that are out of support.

IMHO we should just follow the HTTP standard and have an API to keep backwards compatiblity.