Improve handling of `@JsonTypeInfo`, `defaultImpl` to anchor definition

So: currently it is possible to declare a valid @JsonTypeInfo in basetype, where defaultImpl specifies a subtype that is valid within context of declaration; but use it in a way that triggers an exception for potential conflict.

This happens when user requests deserialization into a subtype of original type, but one that is not castable to the type of defaultImpl. For example, something like:

@JsonTypeInfo(.... defaultImpl=DefaultImpl.class)
public class Base { }

public class Concrete extends Base { }

public class DefaultImpl extends Base { }

where deserialization using:

Base result = mapper.readValue("{ }", Base.class);

succeeds, but attempts to do:

Concrete result = mapper.readValue("{ }", Concrete.class);

will fail, because DefaultImpl is not assignable from Concrete.

While code is not exactly wrong in that there is potential problem – if default implementation ends up required to be used, there would be a cast exception – it is not necessarily something that will happen, and in fact user may be able to either guarantee it will not, or, even if not it may be better to indicate problem only when it does occur as opposed to merely possibly happening.

The technical problem is most likely due to inheritance of @JsonTypeInfo annotation, so that code has no way of knowing where exactly declaration is bound. If binding was known, base type comparison could use Base regardless of expected type, and we could indicate failure only when it actually happens.

It is not 100% certain that this problem can be resolved, but it would be good to try to do so.

[cowtowncoder]

@michalmela As general practice, I add notes on issues if I work on them. So no news unfortunately.

[gm2211]

Had deleted my comment while trying to verify that.

The test for #1565 is actually a little different: you have A(defaultImpl = B.class), B extends A, C extends B and testing that you can deserialize to C.

However, that same PR introduces a test for #1861 -> https://github.com/FasterXML/jackson-databind/commit/09e5ba14fbd519116cbcd23a9ee273bf5d98c7f3#diff-7d961794a75a46f308447cd997960153R54 which is equivalent to the example outlined in this issue.

Not sure about semantic differences either, but this fixes the practical issues we found while upgrading from 2.6.5 to 2.9.5