First outline of fitting result models

[jonc125]

Done as a thinking aloud kind of exercise. I think this is along the right lines, but I'm not sure we want to start from here!

The reason is that we may wish to refactor the Experiment model first so it refers to CachedProtocolVersion and CachedModelVersion instead of storing string SHA values in protocol_version and model_version. When it was originally written, the repocache didn't exist. And then when we first added it we assumed it could be fully ephemeral and just regenerated as needed. But increasingly it is storing data that is expensive to recompute, and the populate method ensures that cache entries are only removed if the corresponding commit is removed, so it is as permanent as our knowledge of the underlying repo. If the commit is removed, we probably do want to remove linked experiment results.

What do you think @sroderick-g5sro ?

Then related thoughts building on this...

• Assuming we do that, we'd want to do the same with FittingResult here.
• I like the Runnable abstraction. In particular, it means that the RunningExperiment table can remain as-is, and indeed receipt of finished experiments in experiments/processing.py:process_callback (and cancelling running experiments) doesn't need any additions for fitting experiments!
• To get submission of fitting experiments to work we'll need a 'fitting' version of experiments/processing.py:submit_experiment that creates the FittingResult etc instances. We may be able to refactor so they share some code though.
• I don't think we want to try automatically migrating existing hacky fitting specs (stored as Protocol instances) to FittingSpec instances etc. Instead manually migrate ones we care about. It seems likely to be too difficult to split the data & spec & protocol file out into sensible places. Would you agree @mirams ?
• We'll need to consider how best to test this as we develop, including building enough of the fitting experiment submission UI to test it out manually.

[mirams]

Yeah, no need to migrate the old hacky specs, there is pretty much only one that people copied and pasted and nobody's using it in anger!

[helenst]

I'm using this as a starting point for work on #134 although since become outdated, a rebase is required. @jonc125 are you happy for me to overwrite / rebase this branch? :)

[jonc125]

You might find it easier to create a new branch off develop rather than rebasing? But I'm happy either way!

[helenst]

Closing so I can create new PR on this branch under my username...