When using serializer context groups in JMS serializer, even if just using the Default group in one place explicitly and leaving it blank in another, they will be treated as different component schemas, even though to the serializer outcome they are the same.
Documenting behavior of decision with side effect.
Previously it was possible to set only one of the min or max values and
get a schema like:
"property": {
"type": "integer",
"minimum": 1,
"maximum": 0
}
Also possible that `Range` would be used with {min,max}PropertyPath and
you'd get a schema with both minimum and max set to zero.
With the checks in place, that's no longer the case.
It's possible to set a count constraint with a min but no max, which
would generate an OpenAPI Schema like...
"property": {
"type": "array",
"minItems": 1,
"maxItems": 0
}
With this change the schema will only set `minItems` in that example.
When using the following requierement:
```
@Rest\QueryParam(name="updatedFrom", strict=true, nullable=true, requirements=@Constraints\DateTime("Y-m-d\TH:i:s"))
```
According to the OpenAPI 3.0 documentation https://swagger.io/specification/, we should have "format": "date-time" rather than "format": "DateTime" in the generated doc
* Apply `enum` from Choice Constraints to Items When Choice is Multiple
Otherwise JSON schema like this is generated:
```
"property": {
"type": "array",
"enum": ["one", "two", "three"],
"items": {
"type": "string"
}
}
```
With this change, however, this schema is generated:
```
"property": {
"type": "array",
"items": {
"type": "string",
"enum": ["one", "two", "three"]
}
}
```
A possible downside here is that the symfony constraint stuff happens
before types are figured out from PHPDoc. So it's _possible_ to end up
with something that won't validated. Take something like this:
```
/**
* @Assert\Choice(multiple=true, choices={"..."})
* @var string
*/
```
This would generate:
```
"property": {
"type": "string",
"items": {
"enum": ["..."]
}
}
```
* Fix CS
* cs
* more cs
* fix tests
Co-authored-by: Guilhem Niot <guilhem@gniot.fr>
