feat: spin off fallback scheduler from the storage scheduler

[victorgarcia98]

Description

This PR spins the fallback mechanism off the StorageScheduler and handles an infeasible schedule by creating a new Job that triggers the fallback scheduler.

TODO

• Add changelog entry
• Explain behavior in the docs Document fallback schedule mechanism #858
• Adapt the FM client trigger_and_get_schedule should fetch fallback schedule flexmeasures-client#69

Related Items

• Issue Fallback schedules should get a distinct source #841
• Issue Log warning in case of an infeasible scheduling problem #842

---

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on code under GPL or other license that is incompatible with FlexMeasures

[Flix6x]

I mostly have minor comments, besides the imo unnecessary chaining restriction and possibly a small but consequential bug: I suspect the fallback scheduler is accidentally using the DataSource of its parent scheduler to save the data (which would undo the primary reason for splitting off the fallback scheduler in the first place). I suggest we explicitly test whether the expected DataSource is present in the database after the fallback scheduler ran.

Very nice test writing btw!

[Flix6x]

(I fixed your mypy issue.)

[Flix6x]

Very nice. I only have very minor comments left. And if you can add a changelog entry, too, I'd be happy to sign off on this feature.

We can then decide to merge after releasing 0.16, or alternatively we create a release branch for 0.16. The reason why I want to keep this out of 0.16 is because we need to provision clients with the means to adapt to these changes, which you already acknowledge in your main PR description:

• Explain behavior in the docs
• Adapt the FM client

I suggest both of these should be follow-up issues.

[victorgarcia98]

I've create two follow up issues:

• Document fallback schedule mechanism #858
• trigger_and_get_schedule should fetch fallback schedule flexmeasures-client#69

[Flix6x]

876ed2c seems not to belong to this PR.