Persist rates and overrides

[raldred]

This PR is work in progress.

I'm looking to propose a solution to the issue where rate are lost for services like IOG and Axle.
If a car is unplugged, the off-peak slots are lost, so cost history is calculated in correctly.
Similar issue occurs if predbat is restarted. Rate overrides are lost.

This aim here is to create a store to persist rates the slot they apply to has past. History of what rates were, should never be forgotten.

[raldred]

@springfall2008 Just putting this up. No rush. It's not complete yet, hence draft status.
Are you happy for me to pursue? Do you have any thoughts on the approach, originally discussed in #2785

[springfall2008]

I understand what you are trying to do here, allow an accurate record of the historical rates after the various overrides.

However there are two much simpler approaches:

1. Just record the current rate predbat is using in a HA sensor, now we have the history.
   or
2. Save the rates from the actual rate table built in fetch, thus removing the need to change lots of components.

The downside to the HA history one is its kind of timing dependent, in that if predbat doesn't update on each period then it might have gaps.

I could implement 2 with very few lines of code, unless you see a downside to that?

[raldred]

Thanks for the feedback! You're absolutely right I think with point 2.

I intentionally created this as separate surface area to avoid polluting the main modules and to avoid stepping on your toes while we figure out the best pattern.
However, in hindsight, it's just added extra complication.

I'm just looking at refactoring this to use the rates table in fetch directly, which would eliminate the need for components to call out to the rate store. So that should be much simpler.

The main issue I haven't been able to solve here, there's a race condition with the current architecture. By default, we only update sensor data every N minutes. If something changes relating to rates from Octopus, Car, Axle, or other components and the change is short lived, we could miss it.

The only real solution would be more frequent sensor updates. Users can achieve this by using the watch list feature, but I expect most people aren't doing that by default.

I don't think it's right to address here, my main goal was, as you say to have a much more accurate record for history and cost calculation, I think that should be a nice improvement on it's own.

I'll update this PR later once I've refactored.