feat: Add cooldown and max_concurrency to SlashCommandGroup

[OmLanke]

Summary

Adds cooldown and max_concurrency to SlashCommandGroup. Since SlashCommandGroup cannot be created using a decorator, these are created manually and passed directly to the init.

Also fixes #1935 by cleaning up the ApplicationCommand.prepare logic. (PR based on discussion in #2057)

Information

• 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, typehinting,
  examples, ...).

Checklist

• I have searched the open pull requests for duplicates.
• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes.
• If type: ignore comments were used, a comment is also left explaining why.
• I have updated the changelog to include these changes.

[codecov]

Codecov Report

Merging #2091 (f472e4f) into master (763b14a) will decrease coverage by 0.02%.
The diff coverage is 0.00%.

❗ Current head f472e4f differs from pull request most recent head cabac19. Consider uploading reports for the commit cabac19 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2091      +/-   ##
==========================================
- Coverage   33.13%   33.11%   -0.02%     
==========================================
  Files          97       97              
  Lines       19141    19151      +10     
==========================================
  Hits         6342     6342              
- Misses      12799    12809      +10     

Flag	Coverage Δ
macos-latest-3.10	33.10% <0.00%> (-0.02%)	⬇️
macos-latest-3.11	33.10% <0.00%> (-0.02%)	⬇️
macos-latest-3.8	33.11% <0.00%> (-0.02%)	⬇️
macos-latest-3.9	33.11% <0.00%> (-0.02%)	⬇️
ubuntu-latest-3.10	33.10% <0.00%> (-0.02%)	⬇️
ubuntu-latest-3.11	33.10% <0.00%> (-0.02%)	⬇️
ubuntu-latest-3.8	33.11% <0.00%> (-0.02%)	⬇️
ubuntu-latest-3.9	33.11% <0.00%> (-0.02%)	⬇️
windows-latest-3.10	33.10% <0.00%> (-0.02%)	⬇️
windows-latest-3.11	33.10% <0.00%> (-0.02%)	⬇️
windows-latest-3.8	33.11% <0.00%> (-0.02%)	⬇️
windows-latest-3.9	33.11% <0.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
discord/commands/core.py	17.77% <0.00%> (-0.22%)	⬇️

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 763b14a...cabac19. Read the comment docs.

[Middledot]

On third thought, since cooldowns and max concurrency can't be used by groups or affect their subcommands, you don't need to implement them. For the confusing formatting, it accounts for the fact that the og pr (#691) removed inheritance of these features, so it just checks one to filter out group objs. Instead of reimplementing cooldowns and max concurrency, you could just reformat the code to something like this:

if not getattr(self, "_max_concurrency", None):
    # For this application, context can be duck-typed as a Message
    await self._max_concurrency.acquire(ctx)  # type: ignore # ctx instead of non-existent message

if hasattr(self, "_buckets"):
    try:
        self._prepare_cooldowns(ctx)
        await self.call_before_hooks(ctx)
    except:
        if not getattr(self, "_max_concurrency", None):
            await self._max_concurrency.release(ctx)  # type: ignore # ctx instead of non-existent message
        raise

[OmLanke]

Since cooldowns and max concurrency can't be used by groups or affect their subcommands, you don't need to implement them.

They actually do control the subcommands. By setting a cooldown/max_con on the group, each individual subcommand gets a shared cooldown/max_con.

So if you had set 1 token per minute as the cooldown on the group, after first cmd invoke, you can't invoke any other command from the parent group for a minute. This also works with subgroups.

So this is actually a valid working feature.

[Middledot]

They actually do control the subcommands. By setting a cooldown/max_con on the group, each individual subcommand gets a shared cooldown/max_con.

I actually confused this and the Invokable pr, because I addressed this there. Prefixed group commands don't have the same behaviour. Their group checks and subcommand checks are independent from each other, so I say the same should be for app commands

[OmLanke]

I actually confused this and the Invokable pr, because I addressed this there.

Oh how?

Prefixed group commands don't have the same behaviour. Their group checks and subcommand checks are independent from each other, so I say the same should be for app commands

The individual cmd's cooldown and max concurrency still apply. You could have 1 per 1 min cooldown on group, while also having 1 per 5 mins on a certain subcommand. (placeholder values for example purposes)

Eg-
Let's say we have group with three commands /dance list, /dance preview, and /dance now.
Let's say we set the cooldown on /dance group as 1 per 1 min. And we set the cooldown for /dance now as 1 per 5 mins.

So now you can invoke only 1 of any of the subcommands in a minute. If the command invoked was /dance now, then you could invoke /dance list or /dance preview after 1 min, but you will need to wait 5 mins to invoke /dance now again.

I hope this makes sense. I should also re-test if the logic I mentioned above actually holds true.

[Middledot]

Oh my bad, I confused it again. What I was talking about were checks of parents being run by subcommands. Cooldowns etc are managed differently. What you're talking about is an interesting use case that I never realized, plus it's consistent with prefixed commands, so yeah, nevermind

[Middledot]

Tested, lgtm!

[Lulalaby]