add oneOf-default-case option for swift5

[Erokha]

Hi, thanks for your tool, it's amazing!
After using it for a while I found out that I need a flag for generating additional default unknown case in OneOf (for client
backward compatibility to avoid decoding fail in earlier client version)
So this is my vision of how it can be done

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/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  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*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.6.0 minor release - breaking changes with fallbacks), 8.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.

[Erokha]

Hi!
I opened an issue #19095, but got but didn't receive any suggestions/critics, so I decided to open a this PR
cc @jgavris @ehyche @Edubits @jaz-ah @4brunu @dydus0x14

[4brunu]

Hi, thanks for creating this PR.
This is a nice improvement.
There is already a flag {{#enumUnknownDefaultCase}}, maybe we can use that flag instead of creating a new one.
What do you think?

[4brunu]

For context, this is the PR that contains the flag that I was talking about #11078

[Erokha]

@4brunu
Hi!
Yeah, in my first venture I used exactly this flag and came across this thing:
When we have schemas like this

components:
  schemas:
    Item1:
      type: object
      required:
        - type
      properties:
        type:
          type: string
          enum:
            - item_1
        similar-value:
            type: string
    Item2:
      type: object
      required:
        - type
      properties:
        type:
          type: string
          enum:
            - item_2
        similar-value:
            type: string
    SomeOneOfItem:
      oneOf:
        - $ref: '#/components/schemas/Item1'
        - $ref: '#/components/schemas/Item2'
      discriminator:
        propertyName: type
        mapping:
          item_1: '#/components/schemas/Item1'
          item_2: '#/components/schemas/Item2'

Tool will generate this swift representation for out items:

public struct Item1: Codable, Hashable {
    public enum ModelType: String, Codable, CaseIterable, CaseIterableDefaultsLast {
        case item1 = "item_1"
        case unknownDefaultOpenApi = "unknown_default_open_api"
    }
   ...
}

public struct Item2: Codable, Hashable {
    public enum ModelType: String, Codable, CaseIterable, CaseIterableDefaultsLast {
        case item2 = "item_2"
        case unknownDefaultOpenApi = "unknown_default_open_api"
    }
   ...
}

What makes decoding errors possible (as an example, we can send json like this)

{
    "type": "new_item_3",
    "similar-value": "I am new item"
}

And it is decoded without errors into any of the Item1 or Item2 structures

So to be safe, I usually turn this flag off. If this is not a strong contradiction for you, it seems to me much more convenient to separate these flags

If I'm wrong somewhere, please correct me.

[4brunu]

Hi, I see.
For me we can keep those as separated flags.

And I would like this to have a more similar name to the other feature, because it's trying to archive the same thing but on a different context.

Would we have conflicts if we give it the same name?
case unknownDefaultOpenApi(let type):
or if we have conflicts something like
case oneOfUnknownDefaultOpenApi(let type):

What do you think of this?

[4brunu]

Hey @Erokha did you had a chance to look into this?
This is a nice improvement that I would like to see it being merged.

[4brunu]

I will merge this as is and do some small tweaks in a different PR. Thanks for creating this PR 👍

[4brunu]

#19753 here is the PR with the changes that we talked above.