Add project-scoped callouts for failed web-hooks

What does this MR do and why?

This MR adds project-scoped callouts for failed web-hooks.

In order to enable this, a new callout table is added: user_namespace_callouts, which at present contains only project-namespace callouts (supporting the project-scoped case) but can eventually be used to replace the user-group-callouts table, which is a specific case of namespaces.

This is guarded by a new feature-flag: webhooks_failed_callout

This is not exposed in the frontend yet, so no observable changes are present in this MR.

See: #365772 (closed)

New database queries:

The follow new database query is used:

# See app/helpers/web_hooks/web_hooks_helper.rb:23
ProjectHook.for_projects(project).disabled.exists?

Which produces the following SQL (here for gitlab-org/gitlab>)

SELECT 1 AS one FROM "web_hooks"
 WHERE "web_hooks"."type" = 'ProjectHook'
   AND "web_hooks"."project_id" = 278964
   AND (recent_failures > 3 OR disabled_until >= '2022-06-27 18:27:30.227635')
   LIMIT 1

Plan:

 Limit  (cost=0.43..4.38 rows=1 width=4) (actual time=58.780..58.781 rows=0 loops=1)
   Buffers: shared read=7
   I/O Timings: read=58.667 write=0.000
   ->  Index Scan using index_web_hooks_on_project_id on public.web_hooks  (cost=0.43..4.38 rows=1 width=4) (actual time=58.777..58.778 rows=0 loops=1)
         Index Cond: (web_hooks.project_id = 278964)
         Filter: (((web_hooks.type)::text = 'ProjectHook'::text) AND ((web_hooks.recent_failures > 3) OR (web_hooks.disabled_until >= '2022-06-27 18:27:30.227635+00'::timestamp with time zone)))
         Rows Removed by Filter: 3
         Buffers: shared read=7
         I/O Timings: read=58.667 write=0.000

Timings from #database-lab:

Time: 60.573 ms
  - planning: 1.743 ms
  - execution: 58.830 ms
    - I/O read: 58.667 ms
    - I/O write: 0.000 ms

Shared buffers:
  - hits: 0 from the buffer pool
  - reads: 7 (~56.00 KiB) from the OS file cache, including disk I/O
  - dirtied: 0
  - writes: 0

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.