Adding 'problems' module

[j-atkins]

Summary

This PR adds a 'problems' module to VirtualShip, whereby as expeditions are run users are faced with authentic problems which may happen on a real-life research vessel. These can be "general" problems (e.g. delayed food/fuel deliveries, unplanned safety drills), or "instrument" problems (e.g. CTD winch breaks down).

Features & implementation

All problems are associated with a delay duration. There are checks of whether there is already enough contingency time built into the schedule to still reach the next waypoint in time. If there is then the simulation is allowed to continue. However, if the next waypoint would be missed, users are prompted to account for the delay in their schedules and the expedition cannot proceed until the scheduling is resolved.

The problems module interacts with Checkpoint objects to test that the scheduling issues have been resolved. A unique record of the problems is also cached to keep track of and determine whether they've been resolved etc. It may be that dealing with a problem at one waypoint causes more scheduling issues way down the chain of waypoints. This is by design (as similar headaches would be experienced in real life!) and the schedule/checkpoint verification methods should capture this and prompt further changes.

The selection of problems and their execution in the main virtualship run workflow is handled by a new ProblemSimulator class. Specific problem scenarios are housed in scenarios.py as problem classes, which are themselves sub-classes of GeneralProblem and InstrumentProblem base classes (to establish a structure for building complexity in further PRs).

When propagated through virtualship run, a selection of all the problems for the expedition is first created but the individual problems are only raised at the right time. For example, a pre-departure problem will occur before any instrument simulations and a CTD related problem only when the CTD instrument is being simulated.

A new 'prob-level' argument is now added to the virtualship run CLI command. There are three options to choose from:

• Level 0 = No problems encountered during the expedition (i.e. turn off problems module).
• Level 1 = 1-2 problems encountered across the expedition [DEFAULT].
• Level 2 = 1 or more problems encountered, depending on expedition length and complexity, where longer and more complex expeditions will encounter more problems.

N.B. I have set the default to prob_level = 1 for now, as this is best for upcoming in-class VirtualShip use.

Additional notes

I have set up the logic so that if waypoints are added/removed from the expedition, if a waypoint location changes or the instruments employed changes, this will prompt a new set of problems for the expedition. I see this as the expedition having materially changed and it being a 'new' expedition. This also prevents just re-running the same expedition until you get a 'nicer' set of problems (without manually removing the problems cache!).

---

Please also note, I still need to add some new tests for the new problems module. These are coming soon, but wanted to get reviews on the vast majority of the changes first.

TODO list:

• Tests

---

Closes #120