Feature: Allow changed operation IDs to be flagged as incompatible

[issy]

When checking a schema for backwards compatibility, changed operation IDs are not flagged as incompatible. Rather, they are detected as a metadata change (see #189) - and therefore not a breaking change. I would like to add a config property to upgrade the change level to INCOMPATIBLE if an operation ID is changed. This is because generated API clients typically use the operation ID to refer to operations, so this would be a breaking change for the generated client.

I appreciate that this may not be desirable behaviour for all users, so I have made the new config property (incompatible.operation.id.changed) default to false (the previous behaviour).

This is my first time contributing to this repo, so please let me know if I've missed something or approached this from the wrong angle.

---

Summary by cubic

Adds a config flag to treat changed operationId as a breaking change for client generators. Default behavior stays the same and treats operationId changes as metadata.

• New Features
  • New option OPERATION_ID_CHANGED ("incompatible.operation.id.changed", default false) to mark operationId changes as INCOMPATIBLE.
  • Added OperationIdDiff and ChangedOperationId; OperationDiff now uses OperationIdDiff to classify operationId changes.

^{Written for commit 76947e0. Summary will update on new commits.}

[cubic-dev-ai]

No issues found across 9 files

[DrSatyr]

@issy looks good and make sense. Thanks for your contribution! Feel free to ping me in case you need new release with these changes ASAP.

[issy]

@DrSatyr thanks for merging! It's not exactly urgent, but I would like to get a release in January at some point if possible. Let me know if that's likely or not