WIP: Re-create actors on dispatch updates

[llucax]

This PR modifies the DispatchManagingActor to re-create the actor when a new dispatch is received and the actor should start running instead of just start/stop the actor. To create the actor a factory function is used, which passes the initial dispatch information to the actor, so it can be properly initialized instead of having the initialization in 2 steps, the creation and the receiving of the dispatch update.

This also removes the support for multiple actors, as it was a very niche feature and makes the code more complicated.

I was also planning to make the updates sender required to simplify the code even further, it should also be very niche for someone not wanting to receive dispatch updates, almost bordering the bug.

Finally, making the DispatchManagingActor a background service instead of an actor and have it manage its own channel. And maybe integrating it to the dispatcher, so the user interface could potentially be as simple as:

dispatcher = Dispatcher(...)
dispatcher.start_handling(
    dispatch_type,
    actor_factory=lambda initial_dispatch, dispatch_updates_receiver: MyActor.new_with_dispatch(..., initial_dispatch, dispatch_update_receiver),
    # in the future maybe also a dispatch merge strategy here
)
...
dispatcher.stop_handling(dispatch_type)

[Marenz]

We don't need this check anymore as the new running_state sender supports filtering by type

[shsms]

I thought this was going to change to self._actors: dict[int, Actor] where the key is int as the dispatch ID, allowing all incoming dispatches to run or frozenset[int] allowing only one dispatch for a given set of batteries.

The power setting actor is using int as key. Is that coming in a separate PR @Marenz?

[llucax]

OK, that's a good point but a separate issue. This was a list of actors in the past only because we some use case actor needed to instantiate many actors when a dispatch arrived only because that actor was not designed properly, this is why this PR removes that.

We need to support the use case you mention too, but I would discuss it elsewhere.

[llucax]

(this PR might not be merged in a LONG time, while the feature you mention should be implemented soon)

[Marenz]

Fyi, I started on a new branch a redesign based on this and the other or, so don't invest time in this currently

[Marenz]

Also, I now accidentally pushed into this pr/branch, sorry. My PR is here: #103

[llucax]

Restored. Although since you took over this I think I will just close. We can reopen if for some strange reason it would become relevant again.