Resolve conflicts when generating Ballerina friendly names from the OpenAPI specification

[TharmiganK]

Description:

There can be conflicts when we try to change the name of a parameter/type/property in the OpenAPI specification using the --use-sanitized-oas option. Those conflicts should be resolved properly.

For example, consider the following components schema:

components:
  schemas:
    response:
      required:
      - value1
      type: object
      properties:
        value1:
          type: string
    Response:
      required:
      - value1
      - value2
      type: object
      properties:
        value1:
          type: number
        value2:
          type: string

The generated name for both Response and response is Response. This will not return a compiler error but one record will overwrite the other which is wrong.

Describe your task(s)

• [ ] Propose a way to resolve the conflicts
• [ ] Implement name conflict resolver in the name proposer component

[TharmiganK]

The conflicts between types can be resolved by adding an numeric suffix incrementally at the end of the type name.

• Example 1:

  initial mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName

  resolved mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName1

• Example 2:

  initial mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName
  currentName3	newName1

  resolved mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName1
  currentName3	newName11

• Example 3:

  initial mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName1
  currentName3	newName

  resolved mapping:	Type name per schema	Proposed name
  currentName1	newName
  currentName2	newName1
  currentName3	newName11

[TharmiganK]

We have observed conflicts in parameter name and the type name in some generated codes.

resource isolated function get v1/accounts/[string account]() returns account|error {
     ...
}

This currently returns a compilation error. The cause of this error is that the parameter of a function can be used as a return type in a dependently-typed function.

With the Ballerina friendly name change this issue will not occur due to the following reasons:

1. With the name change the path parameter will always starts with lower case and the type name will always starts with the upper case, according to the Ballerina naming conventions
2. Currently, we do not change the query or header parameter names. But since the query and header parameters are grouped together as single parameters with custom names generated by the OpenAPI tool (queries and headers), there will not be any conflict with the new type name