Spin off validation logic to separate repository

[pvdbosch]

As was mentioned in https://github.com/belgif/rest-guide/issues/169, there are some concerns of combining the validation logic of (business) values with the problem library.

I'd suggest to spin this off to a separate project because:

• the lifecycle of validation library depends on evolution of business types, not only on technical REST API concerns
• it allows to work towards consolidation with smalsutils-validation
  • we can work on resolving differences while keeping rest-problem-java stable
  • it's very hard to document that a (documented) module of rest-problem-java shouldn't be used in Smals

Some differences with the smalsutils-validation library:

• Smals library uses Bean Validation, also usable outside of a REST context
• Java implementation is kept in sync with validation logic in another Angular validation library
• there are some other validations (like VatNumber country-specific formats), probably some divergent ones as well
• translations of validation errors (useful when library is used in UIs)

Ideally, we could have a single validation logic for Java and integrate with different ways of using it (programmatic validation, bean validation, inside or outside a REST API context, ...)

[jpraet]

Where do you see InputValidationIssues.java fit in? In the problem library or in the validation library?

[pvdbosch]

Good point, I'd put at least the standardized business-agnostic issue types in rest-problem-java (like referencedResourceNotFound).

Not sure about the business-specific ones (like replacedSsin and canceledSsin). It's a bit the same discussion about whether they should be included in the REST guide. Maybe best in the validation library where they can evolve with the validations themselves. Then again, they might be reusable by other validation libraries as well, but that's probably a rather theoretical advantage.