[Java][Spring] fix one of

Created by: Orachigami

Recreated as @wing328 asked

Fixes: https://github.com/OpenAPITools/openapi-generator/issues/2906 Fixes: https://github.com/OpenAPITools/openapi-generator/issues/5381 Fixes: https://github.com/OpenAPITools/openapi-generator/issues/8647 Fixes: https://github.com/OpenAPITools/openapi-generator/issues/8860 Fixes: https://github.com/OpenAPITools/openapi-generator/issues/9601 Fixes: https://github.com/OpenAPITools/openapi-generator/issues/9981

Added tests oneOfModelsGeneration for Java Spring and Java Client which iterate through several specs with OneOf usage cases and check that OneOf models are generated and subtypes implement generated models. Java Client test also creates a cartesian product of specs and client libraries for regress tests.

How inline OneOf models generation is fixed

Added x-deduction and x-deduction-model-names for vendorExtensions. These extensions are used to generated Jackson annotation when the discriminator cannot be used. The discriminator uses the specific field value for deserialization decisions. However, according to the https://swagger.io/specification#discriminator-object first example, oneOf can be used without the discriminator object. This case can be handled with Jackson recently added JsonTypeInfo.Id.DEDUCTION option. DEDUCTION option forces Jackson to make deserialization decisions according to the available fields in the payload and Models which implement oneOf interface/class.

OneOf with Java base classes -> Object

Inline OneOf with Java base classes for RequestSchema and ResponseSchema are replaced with an empty schema. When OneOf is specified it is expected that the output will produce a common interface/class for all schemas in OneOf. All schemas in OneOf also have to implement/extend the generated OneOf model. In the case where users specify OneOf with strings, numbers, dates, etc, the generator is unable to force OneOf implementation for Java base classes (and it shouldn't). So one of the ways to solve an issue is to use Object as the common parent for all base types. Another way to solve this issue is to generate Wrappers for selected base types and force them to implement some common generated OneOf interface.

Example output screenshots

Output examples

Specification usage	OneOf code	Model code

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh

  Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (5.3.0), 6.0.x
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @nmuesch (2021/01)