Add support for Helidon 4 MP client and server generation

[tjquinno]

Resolves https://github.com/OpenAPITools/openapi-generator/issues/18261 to support generation of Helidon 4 MP clients and servers. (A later PR will add support for Helidon 4 SE clients and servers.)

Key changes:

1. Update the pom.xml templates for the Helidon client and server generators:

   • The Helidon MP test component has changed its GAV in 4.x. Conditionalize the pom.xml template accordingly and set a mustache attribute from the Java code to indicate which one to use.
   • The Jandex plug-in has changed its GAV. Conditionalize the pom.xml template and set a mustache attribute from the Java code to indicate which to use.

2. Add support for retrieving the list of released Helidon versions and allowing generator users to specify a prefix for the desired Helidon version.

   The generators now find the highest Helidon release that matches the user-supplied prefix as helidonVersion. The helidon.io website serves a metadata file listing released versions. The Helidon generators attempt to retrieve that list from the website and, if successful, they save the list locally using the Java preferences API. If the internet is not available then previously-stored preferences are used if available and, otherwise, a version list hardcoded in the code is used.

   The PR also contains a new test to exercise this feature.

3. Adjust workflows.

   • Add samples-jdk21.yaml. Helidon 4 requires Java 21, so the samples generated for Helidon 4 do as well.
   • Rename samples-java-helidon.yaml (which deals with samples for Helidon 3) to samples-java-helidon-v3.yaml and change the samples paths to include /v3.
   • Add samples-java-helidon-v4.yaml (which deals with samples for Helidon 4) and use subdirectories /v4.
   • Revise samples-jdk17.yaml to reflect the new locations for the generated Helidon sample projects.

Why so many changed files?

Because the build process for all generators creates sample apps using an OpenAPI document and the various generators, and because this PR puts Helidon 3 samples in a new subdirectory, this PR also moves the sample files that were generated by the previous Helidon 3 generators into the new v3 subdirectory.

The number of changed files in the PR seems very large as a result. The generated Helidon 4 MP apps go into the new v4 subdirectory (to be joined eventually by generated SE samples in a later PR). Doing this allows us to generate samples for multiple Helidon target releases (3 and 4, for now) and avoid collisions between the generated projects while making sure our changes to the generator to support 4.x do not break the generated code for Helidon 3 as we still have active Helidon 3 users.

PR checklist

• [x] Read the contribution guidelines.
• [x] 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.
• [x] 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.
• [x] 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)
• [x] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Attention: @bbdouglas (2017/07) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01) @karismann (2019/03) @Zomzog (2019/04) @lwlee2608 (2019/10) @martin-mfg (2023/08)

[wing328]

https://github.com/OpenAPITools/openapi-generator/actions/runs/9019452156/job/24782576914?pr=18627

thanks for the PR. please update the samples one more time when you've time.

[tjquinno]

I updated the samples locally with no change to the spring ones but I rebased and pushed anyway. This time there is one failed spring job instead of two, again seemingly unrelated to my changes. Perhaps this is an intermittent failure separate from this PR.

I do not seem to have the ability to trigger a rerun of the failed action. If someone else could do that I'd appreciate it.

[wing328]

the failure has nothing to do with this PR and I've asked the test author to take a look: https://github.com/OpenAPITools/openapi-generator/pull/17054#issuecomment-2105932382