Add broadcast messages

What does this MR do and why?

Create broadcast messages when webhook events are blocked or rate-limited.

This change ensures a banner broadcast message is created when a webhook is blocked by rate-limiting, or because it is recursive.

Previously these events were logged, but no notification was sent to the user.

Now, for ProjectHook and GroupHook webhooks, a dismissible broadcast message banner will appear in the UI for OWNER users on the root project and/or root group page.

For SystemHook webhooks, a dismissible broadcast message banner will appear on every admin/* the root /admin page of the UI, visible, therefore, only to ADMIN users.

Only one banner will appear per rate-limited webhook, or for recursive webhook.

References

Screenshots or screen recordings

SystemHook

GroupHook

ProjectHook

How to set up and validate locally

1. Run a server locally to respond to webhook POST requests. (This ruby script by @jnutt does just that)
2. In the gdk create a System Webhook in the Admin area (Admin > System Hooks) using the URL of your localPOST request server (http://localhost:31337 in the example provided)
3. Monkey patch the app/services/web_hook_service.rb to rate limit any request:

--- a/app/services/web_hook_service.rb
+++ b/app/services/web_hook_service.rb
@@ -268,7 +268,8 @@ def safe_response_body(response)
   # Increments rate-limit counter.
   # Returns true if hook should be rate-limited.
   def rate_limit!
-    Gitlab::WebHooks::RateLimiter.new(hook).rate_limit!
+    # Gitlab::WebHooks::RateLimiter.new(hook).rate_limit!
+    true
   end

4. Test the webhook
5. Observe the rate limit failure message in the UI
6. Visit the admin dashboard and note no banner message, visit admin/broadcast_messages and observe no new broadcast messages.
7. Repeat this for Group Hooks and Project Hooks, visiting the group and project root paths and admin/broadcast_messages to confirm no changes.
8. Switch to the 561592-webhook-braodcast-message branch (yes, I spelt broadcast incorrectly 😉) and re-apply the rate_limit! patch
9. repeat the test for each webhook type.
10. Observe in admin/broadcast_messages that banner messages have been created
11. Visit the admin dashboard to see it now display the SystemHook message, and the root group and project paths display the respective Group/ProjectHook messages.
12. Repeat everything for recursion_blocked?

--- a/app/services/web_hook_service.rb
+++ b/app/services/web_hook_service.rb
@@ -272,7 +272,8 @@ def rate_limit!
   end
 
   def recursion_blocked?
-    Gitlab::WebHooks::RecursionDetection.block?(hook)
+    # Gitlab::WebHooks::RecursionDetection.block?(hook)
+    true
   end

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.

Related to #561592