[BUG] Problems with model parameters and form-urlencode

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

I'm not sure where the bugs here are but there are some problems the way parameters are handled for form encoded resource. There is at least a bug somewhere in the code so I'll just talk it through it.

First, I'd prefer these not be filtered at all because filtering and collapsing the parameters makes the generated code inconsistent with the Spec/Documentation. While there is a separate set of documentation generated by this project but I think its a pretty big experience problem for developers when it doesn't match. This seems to be a feature added in #74 and #51. I agree with the idea of filtering unused schemas but these schemas are actually used.

Second, it breaks the ability to use API's with dynamic objects. Marketo for example has a schema that can be customized by admin's, adding fields to different models. It is possible to developer the ability for additionalProperties when the model to the method and serialization but it is impossible when the properties are hard-coded into the signature.

Third, the filtering isn't 100%. In the Person2 example we add the reference different and the filtering doesn't catch it.

openapi-generator version

This seems to affect all versions since the fork. The filtering was added before the 3.0.0 release.

OpenAPI declaration file content or url

openapi: 3.0.0
info:
  title: test
  version: 1.0.0
  contact: {}
security: []
servers: []
paths:
  /person1:
    post:
      operationId: createPerson1
      requestBody:
        content:
          application/x-www-form-urlencoded:
            schema:
              $ref: '#/components/schemas/Person1'
        required: true
      responses:
        default:
          description: Unexpected error
      parameters: []
  /person2:
    post:
      operationId: createPerson2
      requestBody:
        $ref: '#/components/requestBodies/Person2'
      responses:
        default:
          description: Unexpected error
      parameters: []
components:
  requestBodies:
    Person2:
      content:
        application/x-www-form-urlencoded:
          schema:
            $ref: '#/components/schemas/Person2'
      required: true
  schemas:
    Person1:
      type: object
      properties:
        email:
          type: string
          format: email
        enabled:
          type: boolean
    Person2:
      type: object
      properties:
        email:
          type: string
          format: email
        enabled:
          type: boolean
        extra:
          type: array
          items:
            type: string

Command line used for generation

docker run --rm -v ${PWD}:/local/ openapitools/openapi-generator-cli:v3.0.0 generate \
   -i test.yaml -g php -o /local/.build

docker run --rm -v ${PWD}:/local/ openapitools/openapi-generator-cli:latest generate \
   -i test.yaml -g php -o /local/.build

Steps to reproduce

Build and review the generated API.

Related issues/PRs

behavior added by #51/#74

Suggest a fix

My preferences would be to go back to swagger's behavior of using models for forms the same as other content types.

Start by running the documented Docker generation commands with the provided OpenAPI declaration and reviewing the generated PHP client for Person1 and Person2. Compare form-urlencoded handling with other content types, including model properties and additionalProperties; done requires an agreed behavior and coverage of the reported filtering and dynamic-object cases.