[BUG][KOTLIN] Data class not generated correctly when using allOf in array items

[andlbrei]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

When trying to generate kotlin files from Open API spec, a data class without any properties is generated.
In this case the bug is triggered when trying to generate a class from a definition of items in an array containing an allOf.
It seems like the mustache template iterates over allVars to populate the data class, but allVars is empty, being reset in DefaultCodegen.java:L2637
https://github.com/andlbrei/openapi-generator/blob/2b75a9ccdc1a3819e650546d30b94aeb56e99f04/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java#L2637

openapi-generator version

7.8.0
The issue is present in 7.7.0 and 7.6.0 as well.

OpenAPI declaration file content or url

https://github.com/andlbrei/openapi-generator/blob/2b75a9ccdc1a3819e650546d30b94aeb56e99f04/modules/openapi-generator/src/test/resources/3_1/issue_wip.yaml

Generation Details

java -jar openapi-generator-cli.jar generate
-i issue_wip.yaml
-g kotlin
-o .

Steps to reproduce

I made a fork with two tests, and a comment on one line of code that seems to break generation in this case.
andlbrei@d51e3ff

• Create a Open API spec with a schema that contains an array with items that have an allOf with more than one subschema. (It appears that allOf with only one subschema is treated differently, which makes sense)
• Run the kotlin generator with default options.

Related issues/PRs

I have not found a recent issue, though it is hard to be sure with the massive amount of issues that are open here.

Suggest a fix

I have commented on a line of code that impacts generation in this case. When this line is commented out it works.
The code in this library is pretty complicated, and I would assume that "fixing" this case would break something else if done like this.
If someone can guide me, I could make an attempt at fixing it.

[wing328]

can you please file a PR to start with? that would make the code review a lot easier

[andlbrei]

@wing328 created #19905

[wing328]

update: filed #19964 to workaround this for the time being