Allow querying the state of scheduled products by distri/version/flavor

[Martchus]

This will allow us to check whether all jobs we scheduled for a certain purpose (e.g. product increment) are done and whether they have passed.

The details of the lookup are explained in the added API documentation.

The query for this is not super efficient as we don't have an index on the required columns on the scheduled products table. However, it seemed to be fast enough when I tested this with production data.

Related ticket: https://progress.opensuse.org/issues/184690

---

This is an alternative to #6589 which I have started for a hook script based approach. The code is only slightly different, though.

With the approach taken by this PR here we don't need any other changes on the openQA side except for what is provided by the PR right now. Some cron job (e.g. as part of qem-bot) will have to do the checking periodically if there's a pending product increment. However, checking e.g. every hour periodically is probably not that bad compared to adding a hook or event. This is because for a hook/event we would need to check after each job has finished whether the whole assigned scheduled product is finished - which is also lots of checks. (As mentioned on #6589 (comment) this would probably not scale very well.)

This approach also solves the problem of considering only the most recent relevant product. With a hook-based or event-based approach this still needed to be solved in the hook script or event handler with a similar query/request than what is done in this PR with the nested query on scheduled products.

Considering the simplest solution seems to involve only adding a single route to openQA I was also checking whether we might just use an existing route.
I guess the best candidate is this one: https://openqa.suse.de/tests/overview.json?distri=sle&version=15.99&flavor=Online-Increments

I see a few downsides, though:

• It is not an actual API and the API we have doesn't provide grouping/accumulation by state/result. In fact it doesn't return any state/result info at all.
• The info under aggregated could be used to check whether all jobs have passed or whether there are failures. However, we probably also want to mention a list of all failures somewhere and for this we would need to go though a much more nested structure here.
• If the scheduled product is re-scheduled and some jobs are no longer present (e.g. because a test suite has been renamed or removed) then we would still consider jobs from the previous scheduled product.
• We would have to watch out for not accidentally considering other jobs, e.g. investigation jobs. This could be done by specifying relevant group IDs (e.g. &groupid=661).

I don't think any of these downsides would be a strong enough argument to not just use overview.json. However, together they add up so I tend to say that adding the new route is worthwhile.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.11%. Comparing base (87a4d34) to head (9e21701).
Report is 4 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6592   +/-   ##
=======================================
  Coverage   99.11%   99.11%           
=======================================
  Files         399      399           
  Lines       40717    40749   +32     
=======================================
+ Hits        40358    40390   +32     
  Misses        359      359           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Martchus]

With this route it was quite easy to write a script for approving product increments: openSUSE/qem-bot#222

I had to define "ok results" and "final states" in that script but I guess this is ok. So I wouldn't make this route more complicated/specific by using meta states/results.

I changed the route to also consider scheduled products in states "adding" and "scheduling" because those are actually relevant. Those scheduled products will have no jobs yet so we will just return an empty JSON object leading to the "there are no relevant jobs on openQA" case in the script - which is the behavior we most likely want.