[Bug][Kotlin-Spring] Wrong parameter type for multipart-form-data file upload when using kotlin-spring with reactive

[btpnlsl]

#Closes 21548

The kotlin-spring generator allows users to generate Spring Boot controllers & service interfaces for both reactive (Spring WebFlux) or non-reactive (Spring MVC) servers.

The WebFlux or MVC variants of Spring have different mechanisms to support file upload using multipart-form-data.

The kotlin-spring generator is creating controllers & interfaces which are appropriate for Spring MVC, but not for Spring WebFlux, even when the reactive option is set to true in the generator config.

For reactive controllers & interfaces the Kotlin Spring generator should be using org.springframework.http.codec.multipart.Part for file parameters (And using Flux<Part> for arrays of files).

One of the reasons why there is a bit of churn in this PR is because the template logic for determining the class to use for file parameters was put into the optionalDataType.mustache template. IMO, this is not a great place for the logic as the original intent of the optionalDataType.mustache is to manage the Kotlin null safety operator.

For this PR I've pulled the logic for determining the use of MultipartFile / Part into its own template file, fileParamType.mustache. This template is then invoked when the parameter in question is not a body parameter like so:

{{^isBodyParam}}{{#isFile}}{{>fileParamType}}{{/isFile}}{{^isFile}}{{>optionalDataType}}{{/isFile}}{{/isBodyParam}}

Some of the template logic in formParams.mustache is difficult to follow because the template uses different Swagger annotations depending on if the form parameter is for a file or not. The relevant change is in the #isFile section where the use of {{>optionalDataType}} is changed to {{>fileParamType}}. There is probably future work that could be done to simplify the readability of this template by pulling out the swagger annotation logic into its own template.

There is a bit of churn in the unit tests in order to simplify the generation & validation logic to remove a bunch of duplication and make more effective use of TestUtils.assertFileContains to test that the file contains multiple strings.

Oh, and an answer to a potential question: Why not change the type mapping for "file" based on whether the generated code is reactive / not reactive?

AFAIK the use of MultipartFile / Part is just for upload parameters. Download parameters should still be org.springframework.core.io.Resource.

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

  (For Windows users, please run the script in WSL)
  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.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR solves a reported issue, reference it using GitHub's linking syntax (e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Kotlin - @dr4ke616 (2018/08) @karismann (2019/03) @Zomzog (2019/04) @andrewemery (2019/10) @4brunu (2019/11) @yutaka0m (2020/03) @stefankoppier (2022/06) @e5l (2024/10)
Prior Work - PR #20108 - @ffffionn

[btpnlsl]

Closing for now. I spotted a bug in how apiDelegate.mustache is determining handling arrays for non-file, non-reactive situations.