Store mission definition tasks in the source object directly instead of linking to echo

[andchiind]

Describe the improvement you would like to see
Currently the mission definitions mostly just link to echo missions. They basically just act as links to echo and we almost always fetch from echo to make sure the new missions we run are up to date with echo. The only exception is custom missions. I propose that we replace the custom mission string JSON and the link to echo with storing the tasks directly in the flotilla database, and remove the echo dependency in the mission planning. We can then just update mission definitions directly in order to update missions (something we have already been doing to some extent since we overwrite echo mission names already and append zoom levels).

We already have a mission planner ready, which simply needs to call flotilla endpoints instead of echo endpoints to work. The frontend for updating missions does not care what the source is https://github.com/equinor/pointcloud_processing/issues/666 .

The benefits of doing this is many.

• Firstly we remove the problem of constantly coordinating the information in echo mission planner with the mission info we store in flotilla. There would be one correct data model and we wouldn't need to translate between them
• Secondly we will be able to update the model with the information we need without needing to rely on a 3rd party
• Thirdly we will improve access control, as we can, for instance, ensure that only those that can run missions are allowed to create them. This is not a requirement and we can be more lenient, but currently we don't have this control
• Fourthly we will be able to coordinate the data models in Flotilla, ISAR and SARA by using OpenAPI, making maintaining data models easier
• Fifthly we will be able to set analysis type directly in the mission tasks, removing complicated logic and hacky solutions in SARA Use analysis type on inspection data instead of interpreting description sara#329
• Sixthly it is basically required in order to implement variable zoom values properly (Ensuring the option to zoom is user friendly #2624 and https://github.com/equinor/pointilla_maps/issues/21)
• Seventhly we will be able to test the mission editor in a dev environment, or even locally. Currently we are only able to test in production environment, which is far from ideal (this should probably be the first one, but I can't be bothered to change the numbering now)
• Eightly we will be able to create integration tests involving the full mission pipeline. Previously we would either have to access a prod mission database environment in such a test, or simply mock it and hope the model wouldn't change later
• Ninethly we no longer need to maintain custom mission separately from echo missions. There would only be normal missions, which does not care how the mission was first edited
• Tenthly the echo mission planner has a lot of strange quirks which are hard to work around. This change will simplify code in the pointilla mission planner backend

I see no reason to put this off too long, since it will benefit a lot of other tasks and is not that big of a task at this point. This should not be an epic in my opinion, since it can be done in a single PR which is not too big. The only dependency is that we need to update the pointilla mission planner backend, but I developed this backend in such a way that it should be easy to switch out. Besides this the pointilla mission planner needs to request the flotilla role scope, but that is a single line change.

How will this change existing functionality?
We will no longer store references to the echo mission planner database in Source.cs, which is linked in MissionDefinition.cs.

The tasks stored in the database can be more or less identical to what ISAR expects to receive. It could be more or less identical to the MissionTask owned table, except we shouldn't store inspection results there. Although this shouldn't be the case in MissionTask anyways in my opinion. It is probably fine to make the new model also be owned. In echo it wasn't but it's personal preference.

How will this improvement affect the current Threat Model?
It will remove excess 3rd party dependencies which is positive in removing attack vectors.

It also generally gives us full control of access control to the input to Flotilla. Previously that was not the case.

[andchiind]

TLDR: this is not as big of a code change as you might think, it doesn't really need to be an epic, but the gain is big.