[bug] fix null pointer exception while evaluating recommendations

[sebastien-rosset]

A null pointer exception occurs when invoking --validate --recommend if at least one of the parameters in the OAS spec is a $ref.

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]

@jimschubert , I would like to be able to do a validation based on the OpenAPI version (3.0.x versus 3.1). This is bleeding edge, but there are some nice capabilities coming in 3.1, including 'null' type and type arrays. So the recommendation needs to depend on whether the version is 3.0 or 3.1. Should we make the "OpenAPI" object available to the validators? If so, how?

[jimschubert]

@sebastien-rosset that would require updating our parser to one that supports 3.1. Currently, the object model that we pull in is only the 3.0.2 compatible object model. I'd eventually like to have our own parser so we can do the bleeding edge stuff, but that requires getting caught up on a better and maintainable design first.

[sebastien-rosset]

@sebastien-rosset that would require updating our parser to one that supports 3.1. Currently, the object model that we pull in is only the 3.0.2 compatible object model. I'd eventually like to have our own parser so we can do the bleeding edge stuff, but that requires getting caught up on a better and maintainable design first.

Actually, I've been experimenting a bit with the "null" type, which is written as:

type: 'null'

I don't think this requires a new version of the parser because the value of the "type" attribute is still a string. At least I am able to do the things I would like to do. This may be a different story for type arrays, but I'm not there yet.
Now that "nullable" is becoming deprecated on OAS (see my long text on nullable properties), I think I'd rather work on using "type: null" in OneOf that going with something that will be deprecated soon. I also realized it's ok to use OneOf and avoid ugly code because it's possible to control the names of the generated code.

Also, even if at later point a new version of the parser is needed, we still need a way to pass contextual information about the openapi spec. Sometimes the recommendation need to insoect the context