Add a per user rate limit to updating issues, epics and work items

What does this MR do and why?

Adds a rate limit of 600 issue, epic and work item updates every minute for each user, behind the work_item_update_rate_limit feature flag (disabled by default). The limit is the work_item_update_limit application setting, labeled beta in the docs, and 0 turns it off.

The check is the rate_limit DSL on Issues::UpdateService, which every update path runs through, so the REST API, GraphQL and the web UI share one counter. Over the limit, the API and GraphQL return 429 Too Many Requests and the UI shows a plain 429 response. Same pattern as !266323 (merged).

The key is a staged_rule: while the flag is disabled, updates over the limit are counted on limit_work_item_updates_by_user_log and recorded in rate_limit_state, not blocked, so the threshold can be checked before enforcement. Ref: https://docs.gitlab.com/development/application_limits/#roll-out-a-gitlabapplicationratelimiter-key-in-log-mode

Bulk edits count one update for each item on top of their own bulk limit, and a batch with more items than the limit is rejected with 422 before either counter is charged. Member removal and milestone deletion update many items in one system action, so they call execute_without_rate_limiting, as CSV import does for issues_create.

Caps on the labels parameters of these endpoints follow in a separate MR.

References

• Rollout issue: #638508
• Follow-up MR (stacked on this branch): !269378 (merged)

Screenshots or screen recordings

Not applicable: backend and docs only. The UI shows the existing plain 429 response when throttled.

How to set up and validate locally

1. As an administrator, lower the limit: curl --request PUT --header "PRIVATE-TOKEN: <token>" "http://gdk.test:3000/api/v4/application/settings?work_item_update_limit=2"
2. Update an issue three times within a minute, from the API or the issue page. All three succeed, and the request log lines carry applimiter_work_item_update:limit_work_item_updates_by_user_log:log in rate_limit_state.
3. Enable the flag in the Rails console: Feature.enable(:work_item_update_rate_limit)
4. Update the issue three more times within a minute. The third request returns 429, and so does an epic or work item update by the same user.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.