RFC7592: set default values for `grant_types` and `response_types` when updating client

[frankie567]

What kind of change does this PR introduce? (check at least one)

• [x] Bugfix
• [ ] Feature
• [ ] Code style update
• [ ] Refactor
• [ ] Other, please describe:

---

• [x] You consent that the copyright of your pull request source code belongs to Authlib's author.

---

While implementing RFC7592 endpoint in my code base, I noticed a crash could occur when updating the client if grant_types or response_types were not provided:

  File "/Users/fvoron/Development/polar/server/.venv/lib/python3.12/site-packages/authlib/oauth2/rfc7592/endpoint.py", line 147, in _validate_grant_types
    return grant_types_supported.issuperset(set(value))
                                            ^^^^^^^^^^
TypeError: 'NoneType' object is not iterable

In RFC7591 endpoint, there is a fail-safe fallback to avoid this:

https://github.com/lepture/authlib/blob/5ac468051098d544dd5bfad24f692ec1a6bc7ec1/authlib/oauth2/rfc7591/endpoint.py#L110-L114

https://github.com/lepture/authlib/blob/5ac468051098d544dd5bfad24f692ec1a6bc7ec1/authlib/oauth2/rfc7591/endpoint.py#L121-L125

This PR just backports this behavior to RFC7592. The effect is that, if not provided, grant_types and response_types will be set to the default value. From my understanding, this behavior is compliant with the specification:

Omitted fields MUST be treated as null or empty values by the server, indicating the client's request to delete them from the client's registration. The authorization server MAY ignore any null or empty value in the request just as any other value.

[azmeuk]

Thank you @frankie567. For the record, this is a port of #512 for RFC7592. Can you maybe add some unit tests?

[frankie567]

Done! Note that I had to change the setup and an existing assertion to comply with the spec (or, to be fair, my understanding of it 😅)