fix #461: add minlength breaking change detection

[dhananjay12]

Summary

Adds breaking change detection for minLength string property increases in OpenAPI schemas (following the same pattern as existing maxLength validation).

Breaking Change Logic

Context	Change	Breaking?	Reason
Request	minLength: 5 → minLength: 10	✅ Yes	Clients sending strings of length 5-9 will now fail validation
Request	minLength: 10 → minLength: 5	❌ No	Less restrictive - existing clients continue to work
Response	minLength: 5 → minLength: 10	✅ Yes	API contract now guarantees longer strings - may break client expectations
Response	minLength: 10 → minLength: 5	❌ No	API can return shorter strings - compatible change

New Incompatibility Properties

• incompatible.request.min.length.increased=true (enabled by default)
• incompatible.response.min.length.increased=true (enabled by default)

[ctreatma]

I think the breaking/non-breaking decision for minLength in responses may need to be switched. For responses, the concern is existing clients making decisions based on the old specification. If minLength is increased from 5 to 9 in a response, an existing client who is validating that minLength is 5 will still pass; on the other hand, if minLength is decreased from 9 to 5, an existing client who is validating that minLength is 9 will throw errors when the API responds with shorter strings.

Reusing the breaking change table from the issue description:

Context	Change	Breaking?	Reason
Request	minLength: 5 → minLength: 10	✅ Yes	Clients sending strings of length 5-9 will now fail validation
Request	minLength: 10 → minLength: 5	❌ No	Less restrictive - existing clients continue to work
Response	minLength: 5 → minLength: 10	❌ No	API contract now guarantees longer strings - will pass existing response validation based on old min length
Response	minLength: 10 → minLength: 5	✅ Yes	API can return shorter strings - will break existing validation that checks for strings of length at least 10

[dhananjay12]

I think the breaking/non-breaking decision for minLength in responses may need to be switched. For responses, the concern is existing clients making decisions based on the old specification. If minLength is increased from 5 to 9 in a response, an existing client who is validating that minLength is 5 will still pass; on the other hand, if minLength is decreased from 9 to 5, an existing client who is validating that minLength is 9 will throw errors when the API responds with shorter strings.

Reusing the breaking change table from the issue description:

Context Change Breaking? Reason
Request minLength: 5 → minLength: 10 ✅ Yes Clients sending strings of length 5-9 will now fail validation
Request minLength: 10 → minLength: 5 ❌ No Less restrictive - existing clients continue to work
Response minLength: 5 → minLength: 10 ❌ No API contract now guarantees longer strings - will pass existing response validation based on old min length
Response minLength: 10 → minLength: 5 ✅ Yes API can return shorter strings - will break existing validation that checks for strings of length at least 10

My thoughts were similar to exsisting logic of max_lenght in response and clients may have issues if they allocated buffers/UI for the minimum lenght (so a increase in min_lenght 5->10 would be breaking).
If the client is validating a min_lenght value, then it would be breaking anyways in either case. This is where consumer-driven contract testing comes in I guess where the focus is also how the clients use the response (even for optional fields).
Also, I have updated the PR to disable both he request/response for the minor release so shouldn't change any default behaviour now.

[DrSatyr]

@dhananjay12 @ctreatma, from my perspective, there is no silver bullet in this topic. Many discussions in this repo are related to breaking changes detection behaviour, and there is no consensus. So the idea is to keep current behaviour (at least for minor releases) and allow consumers to configure it.

I've created related discussion #724 in order to find out a vision on it for major release which can broke the current behaviour and change the defaults.