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

The base python generator does not currently appear to support the enumUnknownDefaultCase configuration. I'm unsure if this represents a bug report or feature request, specifically because this configuration is documented on the base OpenAPI generator docs here (which I presume would be supported by all generators). This feature allows the generated client to default to a standard unknown value of unknown_default_open_api when the API introduces new or unexpected enum values, thus preventing enum additions or alterations from breaking older generated clients.

I noticed this configuration is supported in other Python generators, such as python-flask, python-blueplanet, and python-aiohttp. However, its absence in the main Python generator requires users to create less than ideal workarounds for maintaining compatibility with new enum values.

Describe the solution you'd like

I would like the Python generator to support the enumUnknownDefaultCase configuration so that it automatically assigns a default value whenever an unknown enum value is encountered. This would allow Python clients generated from OpenAPI specs to handle enum extensions more gracefully.

Describe alternatives you've considered

1. Changing enums to string types in our OpenAPI spec, allowing unknown values to be interpreted as raw strings rather than enums. This avoids errors for unexpected values but sacrifices the type safety and clarity that enums provide.

2. Setting _check_return_type() to False on requests when using the generated SDK, which bypasses type checks for responses. While this method allows unknown values, it also disables type checking for all response fields, potentially allowing unintended data to pass through unchecked.

3. Specifying existing enum types with an anyOf combination that includes both the enum and {} (an empty schema), which permits unknown values by allowing any object to satisfy the type check. However, this approach is less clear and increases complexity in our OpenAPI spec, making it harder to interpret and maintain.

Additional context

N/A