refactor: add DiscriminatorUtils for handling discriminator properties in schemas

[Mattias-Sehlstedt]

Pull Request

Thank you for contributing to swagger-core!

Please fill out the following information to help us review your PR efficiently.

---

Description

Moves Discriminator resolving logic into a separate Utils class.

A commonly requested feature is to extend the discriminator introspection. There exists a PR for this, but I would find it easier to reason about any change if the logic was isolated from the larger monster that is ModelResolver. This so that ModelResolver is not cluttered with more subdomain (managing discriminators) logic, and that the ModelResolver is instead only responsible for exposing an area of these subdomains if there is a reason to provide a helpful extension point.

I.e., Utils provide stateless logic for subdomains of handling specifications, and the ModelResolver mainly combine these smaller parts into something larger.

Type of Change

• 🐛 Bug fix
• ✨ New feature
• ♻️ Refactor (non-breaking change)
• 🧪 Tests
• 📝 Documentation
• 🧹 Chore (build or tooling)

Checklist

• I have added/updated tests as needed
• I have added/updated documentation where applicable
• The PR title is descriptive
• The code builds and passes tests locally
• I have linked related issues (if any)

[ewaostrowska]

Hi @Mattias-Sehlstedt! Thank you for working on improving the code in Swagger Core once again.
We appreciate a lot any intent to make the Model Resolver any smaller :) That's definitely something that needs to be done.

One issue that I see with this refactor is that it is creating a new public API and it seems unintentional. DiscriminatorUtils is public, and both methods are public static methods. Once released, consumers may treat these methods as supported API, creating future compatibility obligations.

The DiscriminatorUtils in this form does not establish a strong public use case. I would keep it internal.

Please consider moving it in the io.swagger.v3.core.jackson package and making it package-private.

[Mattias-Sehlstedt]

I have moved it to the jackson package and made it package private. I have also added a private constructor to align it with the already existing "utils" class there (JAXBAnnotationsHelper). Should it be renamed to Helper too? I personally find Utils to be the more common and descriptive naming pattern.

The other common pattern is to utilize JavaDoc to explicitly state that the signature is volatile/subject to change/internal. But I could not find that the project has done that before so a bit odd to start with it now.