rust: remove Default implementation for enums

[ramosbugs]

PR #15856 removed the derived Default implementations for structs, but left those for enums. Since enums do not have a sensible default (see #10845), they should not have the Default trait implemented either. This is technically a breaking change, but it's also a bug fix since Default itself was a breaking change intended to be removed in 7.0.0.

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.1.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.

cc: @frol @farcaller @richardwhiuk @paladinzh @jacob-pro

[wing328]

cc @Foorack who added these via #10720 to fix regression introduced by #10432 (authored by @PiDelport)

[ramosbugs]

yup, #15856 reverted #10432. this change reverts #10720.

[thesn10]

I would be very thankful if you would introduce a feature flag, as this is also a breaking change.
Even if the Default trait was a mistake in the first place, it was in this library for 2 (!) years and my whole codebase now depends on it.
So I would be very thankful if you would introduce a feature flag :)

[ramosbugs]

@Sngmng: are you referring to a Rust feature flag in the generated code or a flag to control openapi-generator's output?

I think adding a Rust feature flag to the generated code would also be a breaking change since that requires declaring the flag in Cargo.toml, and not all consumers of openapi-generator use the auto-generated Cargo.toml (e.g., I pass --global-property supportingFiles= to openapi-generator and use my own Cargo.toml).

@wing328: Is there a recommended way to flag these sorts of outputs in openapi-generator? Maybe a vendor extension in the OpenAPI spec?

[wing328]

what about adding an option called "generateDefaultTrait" (default to true) so that template can use {{#generateDefaultTrait}} ... {{/generateDefaultTrait}} to include the corresponding code block if needed?