[Java] Fix oneOf discriminator type for inline schemas and allOf inheritance

[pa314159]

Fixes discriminator type resolution in two cases:

• Inline schema (inline enum, URI, …): the oneOf interface getter type now matches the concrete class getter (e.g. FruitTypeEnum, URI) instead of always falling back to String
• allOf inheritance: the discriminator property is resolved recursively when it is declared on a base schema inherited via allOf rather than directly on the oneOf container

Refs #22541, #18693

PR checklist

• Read the contribution guidelines.
• Regenerated Java samples (./bin/generate-samples.sh bin/configs/java*) and committed all changed files.
• @mention technical committee: @OpenAPITools/generator-core-team

---

Summary by cubic

Fixes oneOf discriminator type resolution for inline schemas and allOf inheritance so interface getter types match concrete models (e.g., enum or URI instead of String). Prevents type mismatches and compile errors across Java generators when using oneOf interfaces (refs #22541, #18693).

• Bug Fixes

  • Inline schemas: resolve discriminator type via fromProperty so the oneOf interface uses the real type (inline enum, URI) instead of String.
  • allOf inheritance: recursively find the discriminator property across $ref, allOf, oneOf, and anyOf to use the correct type in the interface.
  • Added cross-generator tests for java (resttemplate), spring, micronaut, helidon, and kotlin-spring; updated oneOfDiscriminator.yaml.

• Dependencies

  • Upgrade Maven Wrapper to 3.9.16 and wrapper to 3.3.4.

^{Written for commit 1a987e3. Summary will update on new commits.}

[Mattias-Sehlstedt]

Hi, I can see that it seems that we have solved almost the same problem at almost the same time (I have #24158).

How would we like to join our work? I believe my solution might not handle non-enums, and your PR also better tracks issues related to this (I am solving this for myself, I had totally forgot that I had been involved with these issues before).

What I would really like to investigate is if your approach could be joined into recursiveGetDiscriminator like what my solution has done, since I do not really see any reason why we would not simple ensure that the original discriminator-parser simple makes sure that it keeps additional data points when it looks for the discriminator property.