Allow strict `LocalDate` parsing

[agusevas]

Per default LocalDateDeserializer deserializes local dates using DateTimeFormatter.ISO_LOCAL_DATE formatter. This formatter uses ResolverStyle.STRICT.

    /**
     * Style to resolve dates and times strictly.
     * <p>
     * Using strict resolution will ensure that all parsed values are within
     * the outer range of valid values for the field. Individual fields may
     * be further processed for strictness.
     * <p>
     * For example, resolving year-month and day-of-month in the ISO calendar
     * system using strict mode will ensure that the day-of-month is valid
     * for the year-month, rejecting invalid values.
     */
    STRICT,

If I use @JsonFormat (i.e. @JsonFormat(pattern = "yyyy-MM-dd", lenient = OptBoolean.FALSE)) the created DateTimeFormatter uses ResolverStyle.SMART. It accepts invalid dates like 2019-11-31.
The default formatter does not accept such dates and throws an error.

To make the behaviour consistent, I suggest setting the DateTimeFormatter to use ResolverStyle.STRICT if the lenient attribute is set to false.

[cowtowncoder]

Sounds reasonable, thank you for suggesting this!

[samwill]

I'd like to work on this!

[cowtowncoder]

@samwill sounds good to me -- PR can be made against master branch, or 2.11 (I can help merging regardless).

The best first step is probably adding a new unit test that shows the problem: I can actually merge that separately, even before/without fix. The only thing to note is that test should go under package that ends with failing, so it will not block build.

[samwill]

Added a PR with a failing test. I think I know how to fix it now; given no hiccups I should have a fix PR tonight or tomorrow morning 🤞

[cowtowncoder]

@samwill Thank you again for the fix! Will be released in 2.11.0.