fix: Don't apply spread operator to strings

[giovannicimolin]

I made some incorrect assumptions on #18154 and as a result the generator ends up applying the spread operator on a string, which is the wrong behavior.

This PR fixes that replacing the spread operation with a ||. This makes the API client have the correct behavior and properly pass the Enum value forward with the correct type.

This doesn't fix the case when discriminator is being used, and I don't know the use case of that or how it works, so I won't touch that code.

I'm not too familiar with the internals, so some guidance in adding tests for this would be a nice extra for this PR.

Testing instructions

I tested this using the APIs from my project.

Relevant details:

• The API Schema had oneOf merging multiple Enums (example on fix: Fix schema generation for oneOf when using TS-FETCH client #18154).
• Use the generated API client and check that the resulting output from a request to the endpoint returns a proper string instead of a dictionary.

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/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  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*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.1.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[giovannicimolin]

@macjohnny The PR I submitted yesterday had an issue so I'm creating this one to address it.
I've tested this using my own app's APIs, so it's working as expected for my specific use case (not using discriminators).

[rickyrombo]

@giovannicimolin I don't think this will have the intended effect of fixing only string enums without breaking the interfaces. The previous code would object assign all relevant interfaces which meant that the resulting object would satisfy constraints for any of them, but the new solution will be "truthy" for the first FromJSONTyped call and early return with only that, which strips the fields from the actual type if it's not the first one.

I'm not sure what the solution is to fix for this but I'm fairly sure this will break folks with "oneOf" w/ objects and not strings/enums

[giovannicimolin]

@rickyrombo Hey! Thanks for the feedback here.

I'm not super experienced in the OpenAPITools, so my knowledge was (and still is) limited here.
I was looking to fix one of the issues that was bothering me and quite a few other users (see original links).

That said, I can work on a fix for this!

Could you give me more details and maybe an API scheme that would break?
Are there any open issues where this fix is currently causing a breakage?
Also, once I come up with a solution, are you up for reviewing it to make sure I don't miss other edge cases?

[macjohnny]

in #18702, the behavior of the oneOf case without discriminator was changed to use the instanceOfXXX functions. I guess without the discriminator, its just hard to correctly infer the type/apply the right transforms