Consider DefaultTyping configuration in Jackson Serializers

[mp911de]

We're exploring whether it makes sense to accept a DefaultTyping config option for Jackson serializer configuration.

Likely, accepting DefaultTyping causes several downstream effects that we actually do not like (e.g. removing typehints for final types such as records likely breaking their support).

[mp911de]

That's a direction I ended up with, too. A single Predicate is likely not going to be sufficient. The code to determine whether to apply default typing contains opinions of ours. We would want to achieve an approach that allows folks to override our opinion or append theirs (that is, take some of our opinions but do something different for a type that we handle or apply/avoid typing for types we don't handle).

What if we introduced a DefaultTypingPredicate interface returning something like YES, NO, I_DONT_HAVE_AN_OPINION allowing functional composition?

DefaultTyping.defaults()
   .and(DefaultTyping.apply((Class<?> it) -> it.isEnum())
   .and(DefaultTyping.skip((Class<?> it) -> it.isPrimitive())
   .and((Class<?> it) -> it.isRecord() ? DefaultTyping.apply() : DefaultTyping.continue());

or

DefaultTyping.defaults()
   .and((Class<?> it) -> it.isRecord() ? DefaultTyping.include() : DefaultTyping.passThrough())
   .and(DefaultTyping.include((Class<?> it) -> it.isEnum()))
//    .andInclude ((Class<?> it) -> it.isEnum())
   .and(DefaultTyping.exclude((Class<?> it) -> it.isPrimitive()))
//   .andExclude((Class<?> it) -> it.isPrimitive())
   .and(MyApplicationSpecificTyping.INSTANCE);

We'd need an idea on naming, though.