feat: Implement support for ArrayMap data type in OpenApi2JaxRs code generation

[matheusandre1]

Closes: #409

Added existingJavaType field to CodegenJavaSchema for better type handling.
Enhanced OpenApi2JaxRs to compute request body types and handle ArrayMap inline.
Updated OpenApiMapDataTypeProcessor to recognize ArrayMap and generate appropriate Java types.
Introduced new test case for ArrayMap inline generation in OpenApi2JaxRsTest.
Added necessary JSON and Java files for ArrayMap support in generated API.

mention it to see the progress.
quarkiverse/quarkus-openapi-generator#1352 (comment) and
and pr : quarkiverse/quarkus-openapi-generator#1611

[EricWittmann]

Thanks for the contribution, Matheus! The ArrayMap feature looks well-motivated and the test demonstrates it working for the core use case. I have a few concerns I'd like to see addressed before merging.

Code duplication — resolveJavaType implemented three times

Nearly identical type-resolution logic (mapping OpenAPI schema types to Java FQCNs) now appears in three places:

• OpenApi2JaxRs.resolveSchemaType() (operates on JsonNode)
• OpenApi2CodegenVisitor.resolveJavaType() (operates on OpenApi31Schema)
• OpenApiMapDataTypeProcessor.resolveJavaType() (operates on OpenApi31Schema)

The last two are almost line-for-line identical. This should be extracted into a shared utility method, likely in CodegenUtil. The JsonNode variant could potentially share logic too, or at minimum the type-name mapping ("string" → "java.lang.String", etc.) should be a shared constant or method.

refToSimpleType produces unqualified names

In OpenApiMapDataTypeProcessor.refToSimpleType(), a $ref like #/components/schemas/ApiList becomes just "ApiList" — the bare schema name, not a fully-qualified class name. But elsewhere (in OpenApi2CodegenVisitor.resolveJavaType() and OpenApi2JaxRs.resolveSchemaType()), refs are resolved to FQCNs via CodegenUtil.schemaRefToFQCN(). This inconsistency is fragile — if the existingJavaType value is ever used directly for import generation or in a context expecting FQCNs, it will silently produce incorrect output.

generateJavaInterface → generateJavaInterfaceSource split

The new generateJavaInterfaceSource method is an exact extract of generateJavaInterface(... topLevelPackage), and the original now just delegates to it. Since OpenApi2Quarkus does not override this method, the refactoring adds an indirection with no current consumer. If this is prep for future subclass work, it should be in a separate PR. Otherwise it can be removed.

Set.of(...) allocated on every iteration

In computeRequestBodyTypes, Set.of("get", "put", "post", ...) is allocated inside the inner forEachRemaining loop — once per HTTP method entry per path. This should be a private static final constant.

computeRequestBodyTypes round-trips the Document through JSON

JsonNode json = mapper.readTree(Library.writeDocumentToJSONString(document));

This serializes the entire OpenAPI document to a JSON string then re-parses it into a Jackson tree. Consider using the data model API directly (as OpenApi2CodegenVisitor does) to avoid the extra allocation.

Inconsistent spacing in generated type strings

OpenApiMapDataTypeProcessor.buildJavaType() produces "java.util.Map<String,String>" (no space after comma), matching the existing convention. But OpenApi2CodegenVisitor.resolveMapJavaType() and OpenApi2JaxRs.resolveSchemaType() produce "java.util.Map<String, ..." (with space). Pick one convention — string equality comparisons on these types would fail silently otherwise.

Minor

• The Javadoc on the new test method references io.apicurio.hub.api.codegen.OpenApi2JaxRs (old package name) instead of io.apitomy — copy-paste from adjacent methods.
• The test fixture pom.xml uses microprofile-openapi-api version 4.0.2 but the project recently upgraded to 4.1.1 — this will likely cause a test failure after the version bump merges. Please verify.