Add rocky REST API for report recipes

[dekkers]

Changes

This adds the rocky REST API to create report recipes.

Issue link

Closes #3526

QA notes

The following calls can be done to test the API using httpie:

List all recipe:

http GET http://127.0.0.1:8000/api/v1/report-recipe/?organization_id=1  "Authorization:Token ..." 

Get details of a single recipe:

http GET http://127.0.0.1:8000/api/v1/report-recipe/cf2676f4-4793-4344-beb6-10b079779b59/?organization_id=1 "Authorization:Token ..."

Create new recipe:

http POST http://127.0.0.1:8000/api/v1/report-recipe/?organization_id=1 report_name_format=test input_recipe:='{"input_oois": ["Hostname|internet|mispo.es","IPAddressV4|internet|134.209.85.72"]}' report_types:='["ipv6-report","mail-report"]' cron_expression="0 0 * * *" "Authorization:Token ..."

Update recipe:

http PUT http://127.0.0.1:8000/api/v1/report-recipe/a019ea3d-9b32-4fce-a502-8a90d5e29756/?organization_id=1 report_name_format=test input_recipe:='{"input_oois": ["Hostname|internet|mispo.es","IPAddressV4|internet|134.209.85.72"]}' report_types:='["ipv6-report","mail-report"]' cron_expression="0 1 * * *" "Authorization:Token c108c9b1adb0bcd6012eadf5602bba2222498b4dd0eac2300fddd9f078bd2eda"

Delete recipe:

http DELETE http://127.0.0.1:8000/api/v1/report-recipe/17978f5e-f1c7-4218-8690-942367fe1960/?organization_id=1  "Authorization:Token c108c9b1adb0bcd6012eadf5602bba2222498b4dd0eac2300fddd9f078bd2eda"

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

[ammar92]

Looks good to me. Had just one tiny remark/ question

[ammar92]

A ConnectError seems quite specific in this case. Perhaps a broader RequestError would also suffice (or TransportError to handle connection errors and timeouts)

[dekkers]

I actually just copypasted patch_schedule and changed patch to delete without thinking about this. Most methods in the SchedulerClient don't catch all the httpx exceptions. I think in most places we should just catch HTTPError, but we should do this in a separate issue / PR.

[underdarknl]

ideally we should not be dealing with the schedulerclient in both this and the other view. We should just be instantiating Schedule objects and calling on their crud methods.
The Schedule object itself would then abstract away the interaction with the SchedulerClient and catch any errors that are HTTP specific.

[ammar92]

Good points. Maybe as an initial improvement to begin with, abstract away all the external dependency exceptions. For example, users that use a SchedulerClient shouldn't necessarily know or care about httpx and its exceptions, but they could expect a higher-level SchedulerError (that could optionally wrap an httpx exception for later reference) and its subclasses. And in the client's response hooks we could catch unhandled httpx exceptions and reraise a proper SchedulerError.

This could be an easy win for simplifying error management and improving maintainability and handle this situation since there are much less exceptions to handle, because we could just act on the generic SchedulerError exception and render the appropriate message.

Obviously this applies to other clients with the codebase and external dependencies.

[underdarknl]

Agreed. The clients should (as we discussed before) just wrap the common errors in an error class for easy consumption by the user. the user shouldnt need to know if the client talks to a database, an api or a filesystem.

[stephanie0x00]

Checklist for QA:

• I have checked out this branch, and successfully ran a fresh make reset.
• I confirmed that there are no unintended functional regressions in this branch:
  • I have managed to pass the onboarding flow
  • Objects and Findings are created properly
  • Tasks are created and completed properly
• I confirmed that the PR's advertised feature or hotfix works as intended.
• I checked the logs for errors and/or warnings and made issues where necessary

What works:

QA steps successfully tested and working. Can also open the report for the deleted report recipe that is present in the History tab.

What doesn't work:

n/a

Bug or feature?:

n/a

[sonarqubecloud]

Quality Gate failed

Failed conditions
41.5% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud