Reject trailing characters in strict date validation

[sahvx655-wq]

Chasing how the strict flag is meant to enforce an exact match in the pattern-based date helpers, I found it rests entirely on datePattern.length() != value.length(). SimpleDateFormat.parse(String) stops at the first character it cannot read instead of failing, so a value whose trailing rubbish keeps the length equal to the pattern walks straight through: formatDate("11/11/199f", "MM/dd/yyyy", true) consumes only 11/11/199, quietly reads the year as 199 and hands back a Date, and GenericValidator.isDate calls the same string valid. The truncated year in a debug trace is what gives it away. The same heuristic sits in GenericTypeValidator.formatDate and in the deprecated DateValidator.isValid that GenericValidator.isDate delegates to, so both accept the garbage.

Both methods now run the parse through a ParsePosition and, when strict, reject the value unless the parse reached the end of it, which is the full-consumption check routines/AbstractFormatValidator.parse already uses. The length comparison stays in place, so an abbreviated field like 2/12/1999 is still rejected and non-strict parsing keeps its current leniency. Left alone, any caller trusting the strict contract to screen malformed dates takes attacker-supplied trailing data and stores a different date from the one submitted.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process.