Better JSON schema support for plugin settings in Rocky

[Donnype]

Changes

Simplify the settings setup to support JSON schema validation from the plugins. This means no add/edit/delete per key, only an upsert (idempotent PUT/create_or_update) and a delete. Since we validate settings as a whole against the schema it makes more sense to treat it as one entity as well.

Issue link

Fixes #464.
Fixes #108.

Proof

Some jsonschema errors in the form:

---

Code Checklist

• All the commits in this PR are properly PGP-signed and verified;
• This PR only contains functionality relevant to the issue; tickets have been created for newly discovered issues.
• I have written unit tests for the changes or fixes I made.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have performed a self-review of my code and refactored it to the best of my abilities.

Communication

• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have made corresponding changes to the documentation, if necessary.

---

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.

[underdarknl]

Nice! functionally this looks like a great step in the right direction.

[github-actions]

File	Coverage
All files	65%	❌
bits/definitions.py	65%	❌
bits/runner.py	56%	❌
bits/https_availability/https_availability.py	93%	✅
bits/oois_in_headers/oois_in_headers.py	57%	❌
bits/spf_discovery/internetnl_spf_parser.py	55%	❌
bits/spf_discovery/spf_discovery.py	72%	❌
octopoes/api/api.py	58%	❌
octopoes/api/models.py	75%	✅
octopoes/api/router.py	46%	❌
octopoes/core/app.py	80%	✅
octopoes/core/service.py	44%	❌
octopoes/events/events.py	96%	✅
octopoes/events/manager.py	65%	❌
octopoes/models/__init__.py	86%	✅
octopoes/models/datetime.py	66%	❌
octopoes/models/exception.py	83%	✅
octopoes/models/origin.py	70%	❌
octopoes/models/path.py	99%	✅
octopoes/models/types.py	95%	✅
octopoes/models/ooi/certificate.py	96%	✅
octopoes/models/ooi/config.py	89%	✅
octopoes/models/ooi/email_security.py	95%	✅
octopoes/models/ooi/findings.py	94%	✅
octopoes/models/ooi/network.py	97%	✅
octopoes/models/ooi/service.py	91%	✅
octopoes/models/ooi/software.py	71%	❌
octopoes/models/ooi/web.py	81%	✅
octopoes/models/ooi/dns/records.py	95%	✅
octopoes/models/ooi/dns/zone.py	77%	✅
octopoes/repositories/ooi_repository.py	39%	❌
octopoes/repositories/origin_parameter_repository.py	53%	❌
octopoes/repositories/origin_repository.py	52%	❌
octopoes/repositories/scan_profile_repository.py	45%	❌
octopoes/xtdb/client.py	49%	❌
octopoes/xtdb/query_builder.py	69%	❌
octopoes/xtdb/related_field_generator.py	71%	❌
tests/conftest.py	88%	✅
tests/integration/test_xtdb_client.py	34%	❌

Minimum allowed coverage is 75%

Generated by 🐒 cobertura-action against 9190bea

[ammar92]

Looks good I don't have much to say except other than that single linter suppression

[Darwinkel]

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.

What works:

• Integer validation works on the nmap boefje
  
  

What doesn't work:

• When a string is entered in the integer field, a success message is given but the field becomes Unset
  
  

[Donnype]

@Darwinkel Firefox seems to send empty strings when you pass text in a number field. (Chromium does not allow text, although you can bypass that.) So I guess this is expected behavior? Also because one of the (optional) fields is actually being set?

[Darwinkel]

@Darwinkel Firefox seems to send empty strings when you pass text in a number field. (Chromium does not allow text, although you can bypass that.) So I guess this is expected behavior? Also because one of the (optional) fields is actually being set?

Fair point. Would it be much work to add a new error message for when text is somehow passed to a number field (or a similar situation)?

[Donnype]

@Darwinkel When actual text is passed to a number field you do see a message of the kind "Enter a whole number" (also see the test cases).