feat(models): mapper refactor

[ssmmnn11]

Description

As described in #552 refactor mappers to enable both flexible graph behaviour, static, dynamic etc.

• simplify mapper structure (Mixins), every mapper has its own pre_process and post_proscess implementation

[JPXKQX]

I've just left some minor comments/questions:

• Some of these comments relate to what should be included in the _init_graph_mode() function, and whether it could do more than just set the graph mode.
• Another point is whether it makes sense to pass the edge_index and edge_attr in the init of the mappers (instead sub_graph and sub_graph_edge_attributes), and whether the selection of the edge attributes should be moved from the mapper to the model.

[matschreiner]

Hi Simon!
Thanks for implementing this, it is really cool!

There still seem to be two parallel control flows: one where graphs are provided externally (dynamic case) and one where they’re provided by the GraphProvider (static case). The purpose of this design is to abstract graph handling into a single place, but it’s still split between two places.

I think either the DynamicGraphProvider should be hooked into the “graph stream” somehow, or the static graph should be provided at the same point in the pipeline as the dynamic graphs are now, so both can be passed consistently into the mappers’ forward methods.

[matschreiner]

LGTM :)

[JPXKQX]

UPDATE: One integration test is failing: test_restart_from_existing_checkpoint.
The migration checkpoint has been implemented to migrate state_dicts, but the test is failing due to incompatible optimiser states. As a result, previous checkpoints can be used for transfer learning, provided that load_weights_only: True is used. Migrating the optimiser states should be possible, but without any contextual information, it is not straightforward and could lead to silent misbehaviour.

[theissenhelen]

If the logic gets moved to the ProjectionGraphProvider, this class could be removed as it essentially just performs a matmul.