fix: correct sibling logic when reading type from schema annotation

[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

Introduces an intermediate fix for the issue reported in #5235. It does not implement fully fleshed type handling (overriding), but rather implements the smallest change possible while still keeping the previous behavior of being able to set AnnotationType's type to String.

Since this changes how @Schema(type = ) is read (the type is now not taken into consideration when resolving to OAS 3.1 in certain scenarios) it could be considered a breaking change. The fallback is to use @Schema(types = ) when resolving to OAS 3.1. See later parts of comment for a reasoning regarding why the application should not try to coerce the types into each other between OAS 3.0 and OAS 3.1, and that they should instead be unaware about each other.

A more extensive fix would be to clarify that this branching is not tied to sibling logic, but rather type coercion. But in order to implement that one would need to reason alot of what is the sought after behavior, especially for OAS 3.1 where there is several types with @Schema(types = {"boolean", "string"}). But all of this is considered out of scope for an immediate fix.

A known "bug" (that exists since before too) is that the underlying type might still leak data. For example with

@Schema(type = "boolean")
public Integer count;

becoming

{
  "count": {
    "type": "boolean",
    "format": "int32"
  }
}

. This occurs since the AnnotatedType does not release the field Integer type when the user specifies boolean. And thus the format is still derived and present from resolving the schema-primitive Integer. But this is as previously stated more so tied to introducing full type overriding functionality.

Fixes: #5235

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)