feat(openapi-generator): Allow for primitives in anyOf/oneOf component schema definitions

[newtork]

Context

https://github.tools.sap/AI/ai-sdk-java-backlog/issues/129

Enable this kind of specification:

components:
  schema:
    Fanta:
      type: object
      properties:
        sodaType:
          type: string
+       flavor:
+         oneOf:
+           - type: string
+           - type: integer
+           - type: array
+             items:
+               type: string
+           - type: object
+             properties:
+               foo: string
+               bar: integer

to generate the code that compiles and allows for deserialization:

public interface FantaFlavor
{
    record InnerString( String value) implements FantaFlavor {}
    @JsonCreator
    static InnerString create( String val )
    {
        return new InnerString(val);
    }

    record InnerInteger( Integer value) implements FantaFlavor {}
    @JsonCreator
    static InnerInteger create( Integer val )
    {
        return new InnerInteger(val);
    }

    record InnerFantaFlavorOneOf( FantaFlavorOneOf value) implements FantaFlavor {}
    @JsonCreator
    static InnerFantaFlavorOneOf create( FantaFlavorOneOf val )
    {
        return new InnerFantaFlavorOneOf(val);
    }
}

Known limitations:

• Deserialization may fail for more than 1 non-primitive option. Jackson is unable to determine the JsonCreator.

Feature scope:

Add feature toggle

• useOneOfCreators

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above
• Error handling created / updated & covered by the tests above
• Documentation updated
• Release notes updated (internal feature toggle)

[CharlesDuboisSAP]

LGTM

[CharlesDuboisSAP]

Why were the other classes (OneOf, AnyOf) not affected by this change?
Why wasn't it there in the first place?

[newtork]

Omg, I went deep into the rabbit hole. I found that our check for (unsupported) anyof / oneof was not sufficient!

• oneOf and anyOf are not checked when they are part of schema root; only when they are deeper in object hierarchy, e.g. when being part of properties fields

See #checkForValidatorsInSchema(JsonNode)

[MatKuhr]

I think this was intentional, because on the root level the generation was already working for some cases. IIRC