[BUG][WIP][GENERATOR] Reserved words are handled inconsitently and wrong

Created by: Fjolnir-Dvorak

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\. If contributing template-only or documentation-only changes which will change sample output, be sure to build the project first.
• Filed the PR against the correct branch: master, 4.1.x, 5.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

Description of the PR

The generator has a feature called isReservedWord which is testing a word if it is reserved in that language or not. The huge problem is that it ignores case why it is not used by most of the generators, got repaired the wrong way introducing new bugs, and got repaired the correct way, but only on a per language base.

This pull request reimplements the feature isReservedWord. The variable reservedWord is completely removed along with its getter and two new private variiables were added, one list ignoring case and one which is case sensitive. The function isReservedWord will check against those two lists whether the word is blocked or not. To register a word to the blocked list I added the functions registerReservedWordsCaseSensitive and registerReservedWordsCaseInsensitive.

For that to work I had to touch each generator and repair the handling of reserved words. That 'caused the java, php and python generator to behave differently than before which must be checked whether it behaves as it should now and did it wrong all the time before, or if I destroyed the code.

The samples will be pushed at last to keep an easy to read an easy to maintain git history

This fix was made because I wanted to fix issue #3428 at first. On further study I noticed the "mess" in the generators why I normalized this feature to make the mentioned bug easy to fig as well as easy to test. The only thing which need to be done to fix that issue is to use the function registerReservedWordsCaseSensitive instead of registerReservedWordsCaseInsensitive. I did not integrate this change yet to keep the sample changes minimal to make it easier to eliminate bugs before I touch every single sample file of the python generator.

Main change made:

modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultCodegen.java

    public void registerReservedWordsCaseInsensitive(Collection<String> reserved) {
        reserved.forEach(it -> this.reservedWordsCaseInsensitive.add(it.toLowerCase(Locale.ROOT)));
    }

    public void registerReservedWordsCaseSensitive(Collection<String> reserved) {
        this.reservedWordsCaseSensitive.addAll(reserved);
    }

    /**
     * This function tests the word against the two sets reservedWordsCaseInsensitive and reservedWordsCaseSensitive.
     * If the word is in any of these lists the method will return true.
     * Attention: The method will return false if word is null!
     *
     * @param word The key which should be checked against the reserved words sets.
     * @return Whether the word is in the reserved sets.
     */
    public final boolean isReservedWord(String word) {
        if (word == null) {
            return false;
        }
        return this.reservedWordsCaseSensitive.contains(word)
                || this.reservedWordsCaseInsensitive.contains(word.toLowerCase(Locale.ROOT));
    }