#24309 [python] Support "default" responses in python client

This makes sure that the python client actually respects the default response type instead of returning None. Making is much more useful.

Would fix #11793 for the python generator.

PR checklist

• Read the contribution guidelines.
• Run the following to build the project and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  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.
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

@cbornet (2017/09) @tomplus (2018/10) @krjakbrjak (2023/02) @fa0311 (2023/10)

---

Summary by cubic

Honor OpenAPI default responses in Python clients by deserializing them when no explicit status mapping matches (including invalid or out-of-range statuses). Fixes #11793.

• Bug Fixes
  • Fallback to 'default' only when no exact or Xxx class match exists, status is missing/invalid/out-of-range, and 'default' is defined in the map.
  • In partial_api.mustache, emit 'default' in _response_types_map for wildcard responses only when a schema is present.
  • Regenerated Python samples and petstore clients to include the 'default' mapping (aiohttp, httpx, httpx-sync, sync, lazyImports, echo_api, legacy-model-dictionaries).