Add knowledge horizon functions to sensor specifications

[Flix6x]

Specifically, the ENTSO-E price sensor should be set up with

knowledge_horizon_fnc="x_days_ago_at_y_o_clock"
knowledge_horizon_par={"x": 1, "y": 12, "z": "Europe/Amsterdam"}  # gate closure of EPEX SPOT

For the other sensors, the default suffices.

[Ahmad-Wahid]

@Flix6x I would need some more explanation to understand this issue.

[Flix6x]

tldr: consider skipping over this issue.

The price sensor is currently set up with the default knowledge horizon function for sensors recording physical events. See https://github.com/SeitaBV/timely-beliefs/blob/main/timely_beliefs/docs/timing.md for background info on the concept of knowledge horizons. The correct knowledge horizon function is given by me above. An example of how to pass this to Sensor.__init__() can be found in the main FlexMeasures conftest.

This issue is a bit tricky, though, because we'd like to make sure that the sensor ID remains unchanged (API users depend on this), rather than a new price sensor being set up whenever this plugin's price import CLI command is run. That involves a database migration that updates the ENTSO-E price sensor entry in the sensor table, AND also recomputes the belief horizons of all previous timed beliefs entries in the timed_belief table for the ENTSO-E price sensor, in a non-trivial manner.[1]

[1] Specifically, by first calculating the belief time from the belief horizon, using the old knowledge horizon function, and then calculating the belief horizon from the belief time, using the new knowledge horizon function. For example, the entry:

• Given an entry with event_start = 2023-05-01T01:00+02:00 and belief_horizon = 11 hours
• Applying the old knowledge horizon function: belief_time = event_start + event_resolution - belief_horizon = 2023-04-31T14:00+02:00
• Applying the new knowledge horizon function: belief_horizon = 2 hours

Complications in this calculation involve timezones and DST transitions, not to mention the fact that we haven't thought through the implications of having a need for a database migration coming from a plugin. I wouldn't recommend picking up this issue right now.