Add an application rate limit to thread resolve and unresolve
What does this merge request do and why?
Thread resolve and unresolve have no application rate limit on any path. This adds a discussions_resolve limit of 120 requests per minute for each user, configurable in Admin > Settings > Network > Thread resolution rate limits and through the discussions_resolve_limit application setting (stored in the rate_limits jsonb column, so no migration).
Discussions::ResolveService, Discussions::UnresolveService, Notes::ResolveService and a new Notes::UnresolveService prepend RateLimitedService, as Issues::CreateService does. GraphQL, REST and web share the limit, and each service call counts once, so every aliased discussionToggleResolve mutation in one GraphQL request counts. The three direct note.unresolve! calls now go through Notes::UnresolveService. The follow-up issue resolve in Issues::CreateService and the resolve_discussion parameter on note creation use execute_without_rate_limiting: the first is not a direct toggle, and the second runs after the note is saved and is already covered by the notes_create limit.
References
https://gitlab.com/gitlab-org/gitlab/-/work_items/606720
Screenshots or screen recordings
| Before | After |
|---|---|
Merge request acceptance checklist
Evaluate this merge request against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.