Enable updating the whole project and its workflow

[jkiviluo]

[This was the initial issue - superseded by the next two comments]

It's cumbersome to include project.json in the git of a Tool like FlexTool (in principle also SpineOpt, but it does it through plugin at the moment), since regular users of a tool are prone to change the workflow in minor ways and also in major ways. We have moved some things away from project.json to a local file, which is good, but it's not always fully satisfactory. Another (parallel) way to deal with this is to use project.json.template. If a Toolbox project directory does not have project.json, but it has project.json.template, it would be automatically copied into project.json when opening that Toolbox project for the first time. Then repository maintainer for that tool can choose to not include project.json in the repository (just have project.json.template).

The downside is that major changes to the workflow (e.g. adding a new tool), won't be automatically included in the workflows of users. To mitigate this at some later point in time, we could have a comparison between user workflow and template workflow to notify the user of changes they could implement in their workflow.

Maybe this issue would be unnecessary if we truly managed to ignore all local changes in a workflow. However, even then, users might sometimes augment the workflow with their own stuff and project.json in the repository would start to deviate from the local one. We could also allow multiple 'local' workflows in the same project alongside an 'official' workflow that can't be modified (except in god mode). So, effectively having multiple project.json files (with different names). However, while maybe desirable, that would be more work and maybe the idea here can be implemented with minimal code (as a first step).

[jkiviluo]

Discussed this with @soininen. This could be taken bit further: The project.json file would be divided into two parts: core that is changed by maintainers only and 'peripheral' that is changed by the user. The core project.json is in git repository and the peripheral is a local file (in this case, there would be no project.json.template, but project_local.json). The maintainer could ensure that for a given project version all the tools in the core work together (version control between tools - light version). And Toolbox could facilitate upgrade of the core project (tools and DBs). This would hopefully make the life of a 'regular user' much nicer (no updating through CLI anymore and everything just works).

One can always just use tool specifications to build their own workflows (in another project folder) if that's what they want (and they know what they're doing).

[jkiviluo]

Here's a mock-up for a user widget, where the user can choose to upgrade to a newer version. It shows what tools in the workflow have been marked (by the developer) as compatible with the project version. Current version is green. (Maybe old versions should be grey - one cannot go back).

Then there should be a button 'upgrade to version', which is available only when the selection cursor is in the new versions. There could also be a button for 'copy project', so that one can go easily test new versions without breaking old (links to outside are an issue).

The developer would define versions these in a YAML or JSON file. Using version tags when available - if not, then SHA-1. Maybe branch should also be visible.

Tools not in git would need to be somehow highlighted. Instead of version tag, there would be 'not in git' in all rows for the tool.

We also need to support versions in our DBs (in addition to Toolbox alembic versions) - and to navigate the combination of Toolbox/alembic DB version and user DB version. That also means a standard way of migrating DBs (at the moment at least SpineOpt and FlexTool do their own migrations).