Add `MapperFeature.REQUIRE_TYPE_ID_FOR_SUBTYPES` to enable/disable strict subtype Type Id handling

[stevestorey]

Describe the bug
In 2.14, if you setup @JsonTypeInfo(use = Id.NAME) then all JSON passed to readValue must include the @type information, but that's no longer true in 2.15, which will now unmarshall JSON with missing type information (as long as no other constraints fail). Although I guess it's possibly something to consider as an improvement, but personally I would like to ensure that clients must pass the type information, not least so that one cannot accidentally send the wrong JSON, but have it pass because it's close enough to the intended type.

Version information
2.15.0-rc2

To Reproduce

Unit test:

import static org.assertj.core.api.Assertions.assertThat;
import static org.junit.jupiter.api.Assertions.assertThrows;

import org.junit.jupiter.api.Test;

import com.fasterxml.jackson.annotation.JsonTypeInfo;
import com.fasterxml.jackson.annotation.JsonTypeInfo.Id;
import com.fasterxml.jackson.annotation.JsonTypeName;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.exc.InvalidTypeIdException;

public class RegressionTest {
    
    @Test
    public void testTypeRequired() throws Exception {
        ObjectMapper om = new ObjectMapper();
        DoSomethingCommand cmd = om.readValue("{\"@type\":\"do-something\"}", DoSomethingCommand.class);
        assertThat(cmd).isNotNull();
        // Prove that we can't load the command _without_ the type information
        // This assertion passes in 2.14, but fails in 2.15 as nothing is thrown and the instance
        // is unmarshalled anyway
        assertThrows(InvalidTypeIdException.class, () -> om.readValue("{}", DoSomethingCommand.class));
    }
}

@JsonTypeInfo(use = Id.NAME)
interface Command {
}

@JsonTypeName("do-something")
class DoSomethingCommand implements Command {
}

/*
 * This highlights why I think it's dangerous to accept the JSON with no type information. A
 * client might accidentally send this structure, but without the type information, which would
 * be rejected in 2.14, but with 2.15 it would be accepted (incorrectly IMHO)
 */
@JsonTypeName("do-something-else")
class DoSomethingElseCommand extends DoSomethingCommand {
}

Expected behavior

The unit test passes, as an InvalidTypeIdException is thrown when no type information is present in the incoming JSON, as was the case in 2.14

[cowtowncoder]

The reason here is that you are not using target type of Command but concrete implementation type -- and fix here is for #2968 (PR #3803), a particularly highly voted issue.
If target type was Command, an exception would be thrown; defaulting only occurs at inheritance levels higher than @JsonTypeInfo (subtype).

I would be open to having a MapperFeature to allow Strict handling of Type Ids, if anyone has time. But it'd have to be added rather quickly to get into 2.15.0.

[stevestorey]

I've created #3854 to add some support for it if there's still time ?

[cowtowncoder]

Thank you @stevestorey -- yes, I think there is. I'll have to think about the question of default settings: in principle, I agree that changes should ideally be Opt-In. The only caveat here is that this is a highly-voted improvement and in some ways it's... one possibility would be to introduce it in 2.15, defaulting to old behavior; then consider change in 2.16; this to have new MapperFeature available bit earlier to make opt-out easier.

Thank you for submitting #3854: I will try to find time to work with it, and will make sure to tackle it before 2.15.0-rc3 gets released.

[cowtowncoder]

Also realizing that maybe for 2.16 there should be added property for @JsonTypeInfo to indicate whether strict type id handling should be enabled for specific base type and its subtypes or not -- should be OptBoolean valued for backwards compatibility.

Created #3877 for possible follow-up work as per my comment.

/cc @JooHyukKim