GH-1129: Add JacksonMimeTypeModule

[artembilan]

Fixes #1129

Introduce a JacksonMimeTypeModule with a simple MimeTypeSerializer
for the proper inter-platform MimeType objects serialization.
Essentially we call its toString() which is enough to carry mime-type
info over the network.
Register this module in the JacksonUtils.enhancedObjectMapper() which
is used from the DefaultKafkaHeaderMapper.
Such a module can be registered as a bean in the application context
and will be automatically discovered by Spring Boot auto-configuration
for Jackson

• Modify a DefaultKafkaHeaderMapper to not deal with MimeType
  directly any more since it is covered by the JacksonMimeTypeModule
  even if MimeType is a part of collection like it is in case of
  mapped HTTP headers.
• Modify DefaultKafkaHeaderMapperTests to check that MimeType is
  properly serialized into its string representation even if it in the
  collection

[garyrussell]

Just one issue.

[garyrussell]

package-protected ctor needed to avoid synthesized ctor with extra arg.

[garyrussell]

Travis (checkstyle).

[garyrussell]

NPE in testTrustedAndNot (travis)

[garyrussell]

I wonder if the deserializer should now (2.3) always decode to String?

[artembilan]

I wonder if the deserializer should now (2.3) always decode to String?

No, that's OK. See my latest commit.

The problem is that even if we serialize MimeType as a String we still store MimeType class in the JSON_TYPES header.

So, if another side is still DefaultKafkaHeaderMapper it is going to deserialize that into MimeType object.
This problem has a place only if MimeType is top level header. If it is an item in the collection, there is choice unless represent it as a plain string.
That's why Jackson always has a containerType, elementType and also keyType for maps.
We store in JSON_TYPES only top-level classes.

Not perfect, but enough so far...
Not sure what is an ideal solution, but in Spring Integration we use init(JsonTypeInfo.Id.CLASS, null).inclusion(JsonTypeInfo.As.PROPERTY); for ObjectMapper.DefaultTypeResolverBuilder to include a type info into the JSON node for particular object.
It may be ignored on the other side, (e.g. by non-Java consumer) or can be used to reconstruct instances properly.
We use such a trick in the GenericJackson2JsonRedisSerializer for RedisMessageStore.

Just some thoughts to share...

[garyrussell]

This broke backwards compatibility; a 3.0 app can't talk to a 2.1 app because the MimeType is no longer a String.