Service transparency and usability: expected data keys, supported representations, unit tests

[thehrh]

• draft PR to enhance visibility of foreseen changes (cf. Let each Stage transparently declare expected and new container keys upon initialisation #809)

• main changes to Stage base class:

  • new expected_container_keys attribute must be set (no deviation from current behaviour if empty/wrong, but unit test likely to fail)
  • new supported_reps attribute may be set (informs new setters for calc_mode and apply_mode)
  • new boolean in_standalone_mode attribute (when set to True: automatically rerun setup() with reset data when calc_mode is changed, but not when set to False, in which case user must take care to rerun pipeline setup manually, see pisa modes guide notebook

• service unit tests:

  • performed by pisa_tests/test_services.py, which is modelled after run_unit_tests.py
  • executed as part of workflow .github/workflows/pythonpackage.yml (each test needs to pass)
  • if given service has non-standard args, requires an init_test function that returns a test instance
  • creates generic (not necessarily physical) toy data with few special cases, tries to set calc_mode and apply_mode, then calls setup() and run()

• resolves Let each Stage transparently declare expected and new container keys upon initialisation #809, resolves ContainerSet's _representation attribute is not set upon initialisation (possibly related to unused data_specs constructor parameter) #811, resolves Bugs in reco.simple_param service #814

[thehrh]

resolves #795

[philippeller]

These are really welcome changes and improvements to the entire codebase!

The PR contains:

• (probably automatic?) formatting changes: not reviewed by me ❔
• changes to the core functions: looking good to me, and are adding explicitness ✅
• changes to the actual stages, mostly reflecting changes in the core: I did not go through each stage 1:1, but changes lookg good from far away ☑️
• more testing: I assume these are fine, since they pass (right?) ❔

[JanWeldert]

The formatting changes were done by Thomas manually. So no automatic tool that can screw up our code.
It took some time but now all stages (except for osc.external' and 'flux.airs' which are ignored) pass their test. That doesn't necessarily mean it makes sense (from a physics point of view) what they do but their implementation works and it is easy to run them with some dummy examples. At the end, this is all we check here.

[philippeller]

Ok, sounds reasonable! From my side green light 🚥