Add support for validating object schemas with no properties defined

[Ben Sayers]

In response body schemas and request body schemas you can declare an object within the schema that has no properties. Right now the validator will reject any mock of this as it will not allow additional properties to be defined. Update the validator to allow additional properties on object definitions that contain no properties.

Options for implementing this:

• Whenever an object with no properties is discovered do not set additional properties to false. This has a negative side effect, if the spec was to be later updated with the property definitions the tool would suddenly start disallowing additional properties. However swagger-diff would not treat this as a breaking change as by default additional properties is true. This can result in broken builds for those whose consumers are using this tool and providers are using swagger-diff. This negative side effect can be addressed by changing swagger-diff.
• Whenever a spec specifically defines additional properties use that value instead of the override. This has a similar negative side effect to the previous option. swagger-diff will not treat the removal of additionalProperties: true as a breaking chance since additionalProperties defaults to true. But it will change the behaviour of this validator. It is also unusual to set additional properties to true as this is the default.
• Stop setting additional properties to false for all objects. This is the least preferred option as this would allow consumers to mock out things not returned by providers by default. In order to prevent this spec creators would need to ensure additional properties is set to false for all objects in their spec - something that will likely be error prone.
• Force users of this tool to fully define their response specifications and make no behaviour change. This may make some unhappy and hurt adoption of the tool.
• Add a flag to turn additional property detections into warnings instead of errors or turn off the check entirely.
• Disable the additional property check only for specific objects via an x-custom-tag in the swagger spec. This may not be possible for services that generate the swagger spec automatically unless there's support to annotate the API code for custom tags

[Ben Sayers]

We need more feedback from users encountering this issue to make a good decision on how to proceed

[Ashwini Rattihalli]

We have a rest api for returning key/value pairs. The Java return type is Map<String, Object>. Our swagger schema for the response looks something like:

responses: {
  200: {
    description: "Result of the search", 
    schema: {
    type: "object",
    additionalProperties: {
      type: "object"
    }
  }
}

Today the validator fails as we have additionalProperties defined for type object. It would help us in our contract testing effort if this can be validated.

[Ben Sayers]

fix: allOf validation ignoring required properties and formats

Close #32

BREAKING CHANGE:

Prior to this change the tool used to disallow additional properties in response mocks unless the schema explicitly allowed additional properties. To support the allOf keyword correctly this behavior has been changed. Now additional properties are allowed in response mocks unless a schema explicitly disallows them. This means some mock responses that were previously considered invalid will now be considered valid.

It is recommended that consumers and providers coordinate upgrading to this release so that both sides agree on what is considered valid vs invalid.

→ <<cset bae1bb7d1a5e>>