Remove job count polling from MR failures widget

What does this MR do and why?

We do not need to poll for the job count in the MR failures widget because we can use the already fetched REST data to know the count. This simplifies the code quite a bit an remove a lot of unnecessary API calls. For example on initial load, if there were 20 pipelines, there we would have needed to make 20 calls to the API to get the count of each pipelines. With this new implementation, we get this data "for free" from the REST API (aka, the mini-graph) as a prop.

We also update the count if the user retries the job from the list of failed jobs, which is graphQL. That way the count is always up to date.

There are no behaviour changes to observe, only that all works well and we removed all unnecessary API calls.

MR table:

Title	Link
Introduce FF and base component	!122914 (merged)
Fetch failed jobs	!122917 (merged)
Display each failed job in a row with log	!122921 (merged)
Add action button to each job row	!123086 (merged)
Add polling when the widget is opened	!124366 (merged)
Removing unnecessary polling	👈🏻 You are here

Screenshots or screen recordings

Showcasing that both versions work, but mostly at the beginning, check the network tab (we removed about a dozen calls, one for each pipeline that were hitting the cache, but still!)

Before	After
Screen_Recording_2023-07-10_at_1.58.54_PM	Screen_Recording_2023-07-10_at_1.59.53_PM

How to set up and validate locally

1. Enable feature flag in rails console `Feature.enable(:ci_job_failures_in_mr)
2. Make sure to have a functioning runner
3. We need a MR with jobs failures. An easy to do so is to make a merge request on the ci config file and add explicit failures
4. Navigate to Build -> Pipeline Editor
5. Change your config to include jobs failures like so:

my_failed_job:
  script: exit 1

1. Create a merge request with that change
2. Navigate to the Merge request page
3. Open the network
4. Go to the pipelines page
5. Notice only 3 graphql calls (none of which are to get the failed jobs count)
6. Click on show failed jobs
7. If your pipeline is running, notice the updates
8. Click "Retry" on any job
9. Notice it updates (polling works!)
10. Retry the entire pipeline
11. Notice it polls!

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.