Validation rules for timed beliefs

[victorgarcia98]

Introduction

Recently, we have introduced the possibility to define some of the parameters of the StorageScheduler as sensors (See #957). This allows defining time-varying values but we are sacrificing some of the data validations that we are performing with quantities. For example, now, it is possible to define a negative power constraint via a sensor.

Ideas

There are at least three moments to consider:

1. When sensor data is UPSERTed
2. When a trigger references a sensor in its flex-model or flex-context
3. When a scheduler GETs sensor data

Gathering some thoughts:

1. When sensor data is UPSERTed

• It's still unknown whether the sensor will even be referenced in a flex-model or flex-context.

2. When a trigger references a sensor

• Allows early validation whose results can be immediately returned to the user.
• Sensor data may still get updated in the time between triggering (creating the scheduling job) and scheduling (executing the scheduling job).

2. When a scheduler GETs sensor data

• Validation against the exact data that would be used in scheduling
• Validation errors would show up in failed task logs.

Originally posted by @Flix6x in #985 (comment)