Codegen parameter for query json serialization

[Mattias-Sehlstedt]

I am interested in implementing so that the Spring http clients can support Json serialization for query parameters.

Since this effort might take a while, especially to get right, I would find it beneficial if the project exposed a codegenParameter which could be used to handle this with a local template-modification until a finished implementation is available in the project.

This PR adds this, in the form of a codegenParameter queryIsJsonMimeType. It can be used as {{#queryIsJsonMimeType}} as a complement to {{#isExplode}} in the api.mustache file to adjust how an object is serialized.

I have also added an endpoint to a sample specification that use query parameters with json serialization, so that it can be seen later how they are affected when a serialization implementation is in place.

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.

[Mattias-Sehlstedt]

There were issues with Build: JDK 11|17 (ubuntu-latest) since it is now using Gradle 9, there was a warning of using the unknown flag -b. I was able to find a fix for this issue since flag -b has been deprecated.

One issue remains with Build: JDK 11 (ubuntu-latest), since Gradle 9 requires JDK 17 or later. This is not something I know how to fix currently (use different Gradle version when running 11?).

Edit: I believe I might have resolved the issue in this PR.

[Mattias-Sehlstedt]

The Python tests looks to be flaky? They have worked previously but now when I rerun them (closing and reopening the PR) there are a random subset that fail each time

[wing328]

fyi. looks like it's working in master: #21723

just restarted the failed job (i saw connection issues, retry max out) and all green now

[wing328]

cc @OpenAPITools/generator-core-team