[MCCS-400]

This merge request will update ska_low_mccs to use the latest version of ska_tango_base.

Release 0.11 of ska_tango_base introduced substantial changes, the most significant being the introduction of component managers, leading to a new device model.

Component managers

These are actually more-or-less the same as our "hardware managers". The name change from "hardware" to "component" reflects the fact that not all Tango devices manage hardware.

Thus, our hardware module needs to be refactored to build on top of ska_tango_base.component. This is a big job that is mostly done.

Device model

The basic device model is:

• Component manager -- A component manager monitors its component, and indicates changes in component state by firing callbacks. Component managers also accept commands, but those commands are largely decoupled from component state. That is, if you can tell a component manager to turn its component on, the component manager might execute that command correctly, but you shouldn't assume the component is actually on until the component manager detects the change of component state and fires a callback telling you that the component is on.

• Callbacks -- Simple callbacks update the Tango device directly. For example, if a Tango device has a temperature attribute, then we would expect a component manager temperature_changed callback to update that attribute. More complex callbacks update the Tango device indirectly, via a some kind of stateful model. For example, callbacks that affect the opState of the device get sent to the opStateModel, which computes and updates opState. Callbacks that affect the health of the device get sent to the healthModel, which comutes and updates healthState.

• Models -- such as OpStateModel and HealthModel, see above.

• Devices -- device setup is very simple now. We simple define our interface, set up our component manager and our models, and link them with callbacks. Device initialisation is decoupled now, so we don't need to initialise on a thread.

Other stuff

I am breaking out each device into its own subpackage as I go. For example, an MccsFoo device would have a subpackage

- foo/
  - __init__.py
  - foo_component_manager.py
  - foo_device.py
  - foo_health_model.py
  - foo_simulator.py

and the unit tests would have

- foo
  - conftest.py
  - test_foo_component_manager.py
  - test_foo_device.py
  - test_foo_simiulator.py

This feels necessary to impose structure on the task, and it is also delivering a bit of MCCS-488.

Status

This is the current status of the update by module/subpackage:

• component -- the hardware module has been largely rewritten into a component module. The hardware module is still there but will be removed once all dependent code has been updated. This is mostly done.
• health -- this will be reduced to couple of classes. There is a new class in there now, temporarily named NewHealthModel. Everything but that is being decommissioned and will go. This is mostly done.
• antenna, APIU, cluster_manager, station, station beam, subarray beam, subrack, tel_state, tile and transient buffer are done.
• subarray and controller are still to do.