[go-experimental] Fix usage of discriminator for oneOf deserialization

[bkabrda]

This PR partially fixes the new style usage of discriminator for better deserialization of oneOf composed schemas. Changes:

• Enables usage of string schemas referenced by $ref as type of the discriminator property (see OneType in example below).
• Removes some unnecessary (AFAICS) logic for unmarshalling - we don't need to check if string(json{{{modelName}}}) == "{}", as we know that json{{{modelName}}} contains at least the discriminator property.

There's one more issue that I'm not sure to address. Consider this example:

openapi: 3.0.0
info:
  title: test
  version: 1.0.0
paths:
  /test:
    patch:
      responses:
        '200':
          description: all good
      requestBody:
        description: request
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Something'
components:
  schemas:
    Something:
      type: object
      oneOf:
        - $ref: '#/components/schemas/One'
        - $ref: '#/components/schemas/Two'
      discriminator:
         propertyName: foobar
         mapping:
           fooone: '#/components/schemas/One'
           footwo: '#/components/schemas/Two'

    OneType:
      type: string
      enum:
        - fooone
    One:
      type: object
      required: [foobar]
      properties:
        foobar:
          $ref: '#/components/schemas/OneType'
        one:
          type: string

    Two:
      type: object
      required: [foobar]
      properties:
        foobar:
          type: string
        two:
          type: string

When I run openapi-generator generate -i min.yaml -g go-experimental -o go --additional-properties useOneOfDiscriminatorLookup=true

I get unmarshaling code like this (even without my change for working with the referenced schema):

// Unmarshal JSON data into one of the pointers in the struct
func (dst *Something) UnmarshalJSON(data []byte) error {
	var err error
	// use discriminator value to speed up the lookup
	var jsonDict map[string]interface{}
	err = json.Unmarshal(data, &jsonDict)
	if err != nil {
		return fmt.Errorf("Failed to unmarshal JSON into map for the discrimintor lookup.")
	}

	// check if the discriminator value is 'One'
	if jsonDict["foobar"] == "One" {
		// try to unmarshal JSON data into One
		err = json.Unmarshal(data, &dst.One)
		if err == nil {
			return nil // data stored in dst.One, return on the first match
		} else {
			dst.One = nil
			return fmt.Errorf("Failed to unmarshal Something as One: %s", err.Error())
		}
	}

	// check if the discriminator value is 'Two'
        // <MORE-CODE>

	// check if the discriminator value is 'fooone'
	if jsonDict["foobar"] == "fooone" {
		// try to unmarshal JSON data into One
		err = json.Unmarshal(data, &dst.One)
		if err == nil {
			return nil // data stored in dst.One, return on the first match
		} else {
			dst.One = nil
			return fmt.Errorf("Failed to unmarshal Something as One: %s", err.Error())
		}
	}

	// check if the discriminator value is 'footwo'
        // <MORE-CODE>

	return nil
}

As you can see, the deserialization logic is generated twice, once for One and once for fooone. The if jsonDict["foobar"] == "One" { line is obviously wrong. I tracked it down to being added at this line. I would like to fix that, but I honestly don't understand the whole purpose of the getOneOfAnyOfDescendants function which returns these results. AFAICS it's redundant and isn't necessary at all, but maybe I'm missing some context. Any help would be appreciated.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project beforehand.
• Run the shell script ./bin/generate-samples.shto update all Petstore samples related to your fix. 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/config/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@antihax (2017/11) @bvwells (2017/12) @grokify (2018/07) @kemokemo (2018/09) @bkabrda (2019/07)

[wing328]

@bkabrda for the issue you mentioned above, can you please open an issue to track it separately if you've not already done so?