Is your feature request related to a problem? Please describe.

Currently, the default value of disallowAdditionalPropertiesIfNotPresent is true, which means that if a schema in the input spec does not specify additionalProperties, the generator treats that the same as additionalProperties: false and generates model code that forbids additional properties. This means that, when using default config, users will generate non-spec-compliant code with overly strict validation rules.

Many of the tests in this repo have code that is wrong based on the input spec. For example, the following test spec does not include any mention of additionalProperties, which means that models that comply with this spec should allow additional properties:

https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/test/resources/3_0/go/allof_multiple_ref_and_discriminator.yaml

However, the test code was generated from that spec with the default disallowAdditionalPropertiesIfNotPresent=true, so the FinalItem model incorrectly forbids additional properties:

https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/others/go/allof_multiple_ref_and_discriminator/model_final_item.go#L198-L200

Describe the solution you'd like

I propose changing the default value of disallowAdditionalPropertiesIfNotPresent from true to false. This will cause openapi-generator to default to generating code that follows OpenAPI standards. The config flag can be maintained for backwards compatibility, but I think keeping it as-is causes unnecessary confusion.

Describe alternatives you've considered

Theoretically, the docs could be improved to more clearly call out the need for users to explicitly set disallowAdditionalPropertiesIfNotPresent to false and a significant number of the tests could be updated to set that flag. However, I think it is preferable for this generator to follow OpenAPI standards by default and doing so will lead to a more consistent experience for users.

Additional context

Since this would involve changing the default value of a config option, it would require a major version bump.