Added functionality for response validation

[daglem]

Code adapted from https://github.com/networknt/light-rest-4j

[stevehu]

@daglem Although light-4j has response validation, it is not used for most cases. The problem is that we need to learn how to add the validation error in the response. You cannot update the response body as it is against the specification. If we add it to the header, it is hard for developers to check it out. Maybe the best place to add the response validation should be in the client module. What do you think? Do you have any better ideas?

[daglem]

@daglem Although light-4j has response validation, it is not used for most cases. The problem is that we need to learn how to add the validation error in the response. You cannot update the response body as it is against the specification. If we add it to the header, it is hard for developers to check it out. Maybe the best place to add the response validation should be in the client module. What do you think? Do you have any better ideas?

The way I'm using validation is either by only logging validation errors in order to verify that the responses conform to the spec, or, if it's considered really important that the response is entirely correct, by returning 500 Internal Server Error with an appropriate error response (defined in the application's OpenAPI spec).

In any case, it must be up to the client whether and how to return validation errors, and any error response(s) should be defined in the application's OpenAPI spec. However the functionality for the validation itself belongs in the validator, which is what I have attempted to provide in the PR.

Regarding error responses, I think it would be helpful if you included three separate fields in the Status object for 1) the non-validated field, 2) any offending value, and 3) the validation error (e.g. "does not match the regex pattern ..."). Currently, I have to extract messages using regexps.