TMSS-860

This ticket aims to deliver a generic way of validating specification json documents on top of the normal json schema validation. It validates rules like: 'do the SAPs in the beamformer match the SAPs in the station_config?' or 'will the station_config yield enough usable stations?' etc.

I've implemented this as follows:

• in the AbstractTemplate class there is the validate_document method, which in turn calls the validate_document_against_schema and the (new) validate_document_against_rules method.
• the validate_document_against_schema is implemented for all schema using subclasses.
• the validate_document_against_rules is empty, and can be overridden by each specific template.
  • for example, the TaskTemplate class implements various generic and observation specific validation rules.
  • for example, the SchedulingUnitTemplate class overrides validate_document_against_rules and calls the validation method on each task in the document, and for the constraints.
  • in the future, when needed, we can add new validation rules in the appropriate AbstractTemplate subclass, without the need of implementing extra calls or endpoints to evaulate these new rules (see next point).
• there is one (new) validation endpoint per template in the REST API /api/<template_type>/<id>/validate_specifications_doc where the user can submit a json_doc and get a validation result back.
  • this endpoint is intended to be used in an "interactive" way: the user edits some field in the doc, submits it for validation, and be happy with the valid result, or be sad that his edit was invalid, but now he knows how to make it valid thanks to to error message.
• The same AbstractTemplate.validate_document is called when creating a blueprint from a draft. If the draft is not valid, the blueprint is not created. This prevents many "errors down the line" and lots of support work.
• As a proof of concept I've implemented the "interactive" behaviour in the frontend for editing Task specifications. This works.
  • I've created a linked ticket for the FE team to implement similar "interactive" behaviour for the scheduling unit and constraints.

For the rest this is a big changeset, mainly because I needed to fix many tests. Either in the test setup, or in the used templates, or sometimes with a small code fix. I'm quite happy that this new extra validation step exposed so many poorly validated tests. The overall robustness has increased!

Hint(s) for the reviewer:

• focus on the AbstractTemplate validate_document validate_document_against_schema and validate_document_against_rules methods. Check the overrides of validate_document_against_rules
• glance over the rest.

Closes TMSS-860