Add server and client generators for Helidon

Created by: tjquinno

Resolves #13367 (closed)

This PR adds two new generators:

• java-helidon-server for Helidon servers, and
• java-helidon-client for Helidon clients.

Further, each generator has two libraries: se and mp corresponding to Helidon's two "flavors" which expose quite different APIs and, therefore, require quite different generated code.

Background

Some time ago, existing generators were enhanced to support earlier releases of Helidon. But the support was not as complete (given the server/client and MP/SE components of Helidon) as we would like or as users should expect.

Rationale

Building two new generators, rather than changing existing generators, is clearer (we believe) for end users and simpler in the OpenAPITools code.

Users of the new generators can rely on the familiar hierarchy of generator+plus+library to choose server vs. client and SE vs. MP, rather than specifying one ore more less-obvious command-line options or additional properties.

In the OpenAPITools code, this approach allows for simpler templates and Java code in the generator itself, avoiding excessive conditionality in templates and in the Java classes that would otherwise have been needed. This approach also insulates the code for other generators from our work; this PR changes no other generator code or templates and the same will be true of future revisions to the new Helidon generators.

This is also the same approach taken when support for some other frameworks was added to OpenAPITools.

Testing

The new generators include several unit tests and functional tests which exercise all four combinations of the two new generators and their libraries. We have also done manual testing with various settings of additional properties.

Speaking of functional tests, this PR also adds a new step to the openapi-generator.yaml GitHub action workflow. This new step detects (using a naming convention) and executes any functional tests, tests which by convention invoke a generator and then run mvn package in a process, examining the process output to make sure the generated project builds successfully. The step runs twice, once each with Java 11 and Java 17; different releases of Helidon expect different Java versions which might be different from the Java version being used to build OpenAPITools itself. The PR includes several Helidon-specific functional tests, but note that the GitHub action addition is generic.

Organization of the PR

We have prepared the PR to contain nine commits, each containing a more-or-less related group of changes and with (we intend) helpful commit messages. Using multiple commits is partly so reviewers can, if they wish, look at the changes commit-by-commit to "chunk" the work a bit. We used several commits also because several people have participated in this work and we want to recognize everyone's contributions.

---

NOTE - We request that, if possible, once approved this PR be merged without squishing so as to preserve the authorship of those contributions.

---

Java technical committee, please take note: @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)

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/utils/export_docs_generators.sh

  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*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (6.1.0) (minor release - breaking changes with fallbacks), 7.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.