Jakarta Validation 4.0

The Jakarta Validation 4.0 release will upgrade the language level requirements and consider outstanding feature requests such as:

• - Actually deprecate the methods in `ConstraintViolationBuilder`,
  i.e. add `@Deprecated(since = "1.1", forRemoval = true)`, where there's currently just a Javadoc comment (`@deprecated`).
- Introduce the `ConstraintValidator#initialize(ConstraintDescriptor<A>, ConstraintValidatorInitializationContext)` to provide access to more information at constraint initialization step (e.g. `ClockProvider`, implementation specific context, etc.).
- Introduce `ConstraintDescriptor#getAttribute(String attributeName, Class<V> type)` to simplify working with constraint attributes.
- Clarify what happens when mixing inheritance and default group redefinition (https://hibernate.atlassian.net/browse/BVAL-711)
- Fix incorrect example in table 5.1 (https://hibernate.atlassian.net/browse/BVAL-698)
- In the XSD, relax the order of elements where the order does not matter (https://hibernate.atlassian.net/browse/BVAL-694)
- Clarify that behavior is undefined if legacy @Valid and type argument @Valid are given for same element, while at the same time encourage implementations to issue a warning to the users, as in the future spec version we are planning to enforce more strict rules and not support the "legacy" format anymore. (https://hibernate.atlassian.net/browse/BVAL-709)
- Support ConstraintValidator declaration via service loader (https://hibernate.atlassian.net/browse/BVAL-645)

- Drop use of `SecurityManager` (already done, but not a part of 3.1)
- Set the minimum JDK version (21 for Jakarta EE 12 ?)

-------------------
From GH issues ( (+) - yes, (?) - need to think through first, (-) - no):
- (+) address TCK challenge `@Min` validation a String (https://github.com/jakartaee/validation-tck/issues/194)
- (+) Modernize the build (as a follow-up to https://github.com/jakartaee/validation-spec/issues/282)
  - flatten the pom to remove unnecessary build information
  - bump plugin/testng versions
- (?) Add optional "groups" attribute to @Valid (https://github.com/jakartaee/validation-spec/issues/269).
  Suggested behavior:
    > there is no way to specify which groups must be validated does not make sense as this will be determined by the groups on the object we cascade into. But what's described in the comment (allowing to move the cascading validation to a specific group), might be an interesting improvement (need to think through the consequences first though)
- (-) GroupSequenceProvider https://github.com/jakartaee/validation-spec/issues/268 (I would leave this one out for now)
- (-) Enforce constraint validators to support injection if CDI https://github.com/jakartaee/validation-spec/issues/266 (I would leave this one as is for now)
- (-) Add @ValidEnum Constraint for Enum Validation (https://github.com/jakartaee/validation/issues/229)
  Ignore for now, the user started implementing this constraint at the HV level.
  Let's complete that work first and get some feedback.
- (-) https://github.com/jakartaee/validation/issues/230 (just close this one, BV 2.0+ already supports this)
- (-) Be able to compose Pattern list with OR expression (https://github.com/jakartaee/validation/issues/157). Patterns can be OR-ed within the regex itself; as for `@ConstraintComposition` -- while HV has it,  We haven't seen it widely used, hence let's not push it to the spec yet
- (-) Support the Valid annotation on parameterized types to an interface class (https://github.com/jakartaee/validation/issues/186).
  This fails the idea of constraint definitions; I'd just close it.
- (?) Empty Optional<@NotBlank String> fails validation https://github.com/jakartaee/validation/issues/222
  We should address this requirement from "4.3. Built-in value extractors", it'll be a breaking change:
• java.util.Optional; value() must be invoked, passing null as node name and passing the contained object as value or null if none is present
    Additionally, I'd like to find out why we went this route initially.
- (?) Provide access to unwrapped value for ConstraintViolation https://github.com/jakartaee/validation/issues/194.
  Need time to investigate. It might just be a Spring implementation problem rather than a spec problem.

-------------------

While in HV, let's explore:

- Array element annotations. This will most likely require some breaking changes, similar to removing legacy `@Valid` support.
  Let's experiment with it a bit first before pushing something to the spec (https://github.com/jakartaee/validation-spec/issues/282)
- warn users about the misuse of the constraint annotation, so that we can then break the "legacy approach" in the following major.
- Explore support for constraint ordering (http://beanvalidation.org/proposals/BVAL-248)
- Work on more built-in constraints (e.g. the `ValidEnum` from the spec suggestions; btw it already transformed into something more generic.)