feat: user apps

[shiftinv]

Summary

discord/discord-api-docs@1eaa1af :woo:

This is still wip. The current state already works fine, just a few rough edges.
The API isn't... great. Particularly some of the terminology/naming used is just confusing, and some parts are just completely nontransparent wrt. defaults and fields taking priority over others. It is what it is. /shrug

Issues

A probably non-exhaustive list of things that are still missing, could be improved, or are still uncertain.

API issues/unclear behavior:

1. contexts does not default to [0, 1, 2] on the api side, despite the documentation's claims.
   • resolved: this shouldn't matter
2. It's not clear how Application.install_params and .integration_types_config work together. Right now it seems that the latter takes precedence over the former, if set. The dev portal sends both, looks like the API isn't doing any data shuffling here.
3. Same thing goes for ApplicationCommand.dm_permission and .contexts. I'm not sure if we even want to deprecate dm_permission right now.
   • resolved: deprecated dm_permission; if both are set, we raise an exception. fwiw, if both are sent, the API prefers contexts over dm_permission
4. We might want to send a fixed default value for contexts instead of the current null, in case the API ever starts choosing for us.
   • resolved: likely not needed, and can be fixed trivially if it ever happens. worse case is that we sync unnecessarily
5. The authorizing_integration_owners field is weird, and its structure varies heavily based on configuration/context of commands and interactions. It already has a lengthy docstring, but it might be easier to instead split it into two separate properties and add some of our own fallbacks.
6. message.interaction_metadata.name isn't documented - quote, "well it will still be there, but i dont want to officially document it". It's an optional field, so implementing it nonetheless is probably fine.

Bugs/Missing features:

7. This needs feat(interactions): deserialize channel from data #1012, feat: deserialize dm/group channels in interactions #1233. Additionally, feat!: use the guild data provided on interactions #1236 for the guild attribute in guilds without the bot user. And then likely a ton of mocking for guild.me and several permissions-related methods. Still very uncertain about this part.
8. The GuildCommandInteraction annotation (which ends up setting dm_permission=False) silently conflicts with the contexts parameter. See 3.
   • resolved: the annotation now sets contexts = InteractionContextTypes(guild=True) instead of dm_permission = False

QOL:

9. Bot-wide defaults for the two new command fields could be useful, but aren't trivial to implement. Might hold off on this for now.
10. There are no utility decorators yet (like @commands.default_member_permissions()).
11. Allowing a command e.g. in all contexts is very verbose due to contexts=[InteractionContextType.guild, ..., ...]. An .all() property on the two new enums could be useful, but also feels a bit weird. Might be resolved by 10. eventually.
    • resolved: the enums were turned into flags, which also have .all()
12. As mentioned, the official naming is weird. "interaction context" vs "installation context"/"integration type" is easy to mix up, and "integration type" in itself just seems... wrong. Considering renaming all integration_types to installation_types (the one combination of these words that the api docs don't use!).
13. More naming stuff can be found at various TODOs in the code.

Documentation:

14. The docs page still needs updates.
15. changelog tbd

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[DJStompZone]

12. As mentioned, the official naming is weird. "interaction context" vs "installation context"/"integration type" is easy to mix up, and "integration type" in itself just seems... wrong. Considering renaming all integration_types to installation_types (the one combination of these words that the api docs don't use!).

I agree that the naming is weird, and it still may change. But personally I feel like naming things similarly but differently compared to the discord docs could just wind up adding unnecessary confusion to an already murky situation. Especially for people trying to search by specific keywords.

[onerandomusername]

This should have a way to automatically apply the same context to every single command. Like a bot default_contexts parameter.

[onerandomusername]

DM Permission requires a bit more work (shouldn't impact user-facing side, should not actually touch the API) but this was the quickest change to make it no longer touch the API

[onerandomusername]

@shiftinv could you separate the stuff for app info (disnake/appinfo.py, disnake.utils.oauth_url, etc) into a separate pr? Those don't need to be a part of this PR.