fix(oas3): request body validation

[glowcloud]

Refs #9673

Request body with content type application/json should now correctly validate missing required values and incorrect value types, and show errors.

I had an issue with making it work for application/x-www-form-urlencoded. I could validate types, which was missing before, but empty values would incorrectly show errors if the parameter type was different than string. This is because the value would be an empty string then, and the method would see that as an error. As such, I went back to the version that worked for application/json for now.

There is also one e2e test that will not pass, because it expects that a request body with a single space " " will be validated as correct. With my changes it's as invalid JSON:

I'm not sure if I should update the test or if the previous behaviour was correct, and I should change the validation.

[glowcloud]

Here's where we set the error because of which the test fails: https://github.com/swagger-api/swagger-ui/blob/cebccaa8745662d61cdefdbad3646034cd15d4f8/src/core/utils/index.js#L481-L488 Looks like we can't parse " ".

The same thing happens for OpenAPI 2.0 (without changes in this PR)

Apart from that, even if that JSON error wasn't set, the test shouldn't pass because the schema has required properties:

which we don't specify in the test.

We can change to the current behaviour by changing this https://github.com/swagger-api/swagger-ui/blob/8fc64e726f61ba311e5e84b2ea94f7035aefffb8/src/core/plugins/oas3/selectors.js#L311-L326 to something like this

export const validateValues = (
  state,
  { 
    oas3RequestBody, 
    oas3RequestContentType, 
    oas3RequestBodyValue 
  }
) => {
  if (oas3RequestContentType === "application/json") {
    try {
      JSON.parse(oas3RequestBodyValue)
      return validateParam(oas3RequestBody, oas3RequestBodyValue, {
        bypassRequiredCheck: false,
        isOAS3: true,
      })
    } catch (e) {
      return []
    }
  }
  return []
}

but if we're missing the required properties, or the JSON is malformed, ex. doing something like this

{
  "name": 123
}12345

the input won't be invalid. This is the current behaviour for 3.x