[java][jersey2] Add support for discriminator, fix nullable typo and nullable deserialization

[sebastien-rosset]

1. Fix nullable typo, the mustache template had isNulalble
2. Add support for discriminator in jersey2 library.
3. The deserialization code was incorrectly accepting null as input data for non-nullable anyOf/oneOf schemas. If the input data is null and the anyOf/oneOf does not accept null (either because nullable: true or type: 'null' is a child anyOf/oneOf, then a deserialization exception should be raised. Note: it's likely this problem exists for other schema types too.
4. When there is more than one level of anyOf/oneOf, the deserialization was previously failing. This is shown with the existing sample OAS 3.0 doc that works with the python and go clients.

Newly discovered issues:

1. The existing jersey2 implementation of oneOf/anyOf is incomplete. It is supposed to validate the input data against the JSON schema, but it does not validate any constraint (enum, min, max...)
2. Other issues listed with TODO comments in the Unit test file.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

[sebastien-rosset]

@wing328 , I have temporarily commented out this code. If I enable it, then deserialization fails and the unit test fails. It looks like there is a problem when a compose schema (Drawing) has the additionalProperties keyword, in which case the generated Drawing.class extends from HashMap<String, X>

[sebastien-rosset]

@wing328 , is there a better way to fail deserialization of the null value that would work across all OAS schema types?

[sebastien-rosset]

@wing328 , it's a bit hacky for now, I'd rather not use a public method, but it's needed to have proper deserialization when there are multiple levels of oneOf/anyOf.

[wing328]

The CircleCI failed with the following errors (partial):

[ERROR] location: class JSON
[ERROR] /home/circleci/OpenAPITools/openapi-generator/samples/client/petstore/java/jersey2-java8/src/main/java/org/openapitools/client/JSON.java:[256,45] error: cannot find symbol
[ERROR] symbol:   class IsoscelesTriangle
[ERROR] location: class JSON
[ERROR] /home/circleci/OpenAPITools/openapi-generator/samples/client/petstore/java/jersey2-java8/src/main/java/org/openapitools/client/JSON.java:[257,43] error: cannot find symbol
[ERROR] symbol:   class ScaleneTriangle
[ERROR] location: class JSON
[ERROR] /home/circleci/OpenAPITools/openapi-generator/samples/client/petstore/java/jersey2-java8/src/main/java/org/openapitools/client/JSON.java:[258,36] error: cannot find symbol
[ERROR] symbol:   class Triangle
[ERROR] location: class JSON
[ERROR] /home/circleci/OpenAPITools/openapi-generator/samples/client/petstore/java/jersey2-java8/src/main/java/org/openapitools/client/JSON.java:[259,30] error: cannot find symbol
[ERROR] symbol:   class Triangle
[ERROR] location: class JSON
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 

I'll merge it into a branch first and further improve it.

[sebastien-rosset]

For additionalProperties, I propose to use a Java field of type Map<String, X> instead of currently using class inheritance. The reason is that 1) additionalProperties keyword can be used with allOf composed schema, and 2) it makes more sense to use class inheritance for allOf rather than additionalProperties.

This would require a custom java deserializer.