A0-2884: Refactor alerter

[woocash2]

Refactor alerter to make it possible for synchronous simulation.

• Separate the alerts module into synchronous handler and service with a single async method (Alerter is now Handler and Service contains the run logic)
• Make possible to create Service and Handler before running the service

A delicate change: changed signature of rmc and io to not take keychain by reference but by value. This was needed because keychain is now passed to Service::new where it is passed further to Handler (old Alerter) and IO. It can't be passed by reference to them because of the lifetime issues. Instead we pass cloned keychain to both of them by value.

If we really want keychain to remain passed by reference we can probably implement it by using Rc.

[github-actions]

Please make sure the following happened

• Appropriate tests created
• Infrastructure updated accordingly
• Updated existing documentation
• New documentation created
• Version bumped if breaking changes

[timorl]

You should be able to construct the Handler and use that for the simulation rather than Service. Plus some other comments about the general architecture of this kind of split, mostly that logging should happen in the Service.

[woocash2]

you're right, so it's already possible to create Handler and call its methods, but I suppose that some component for simulation and message aggregation is needed.
I'll proceed with adjusting errors, logging and access to methods and I'll add the simulation in the next PR

[timorl]

Still some comments.

[fixxxedpoint]

LGTM. Suggestion: consider implementing a more direct approach instead of simulation. I don't know how exactly your interactions with Handler will look like but in general a safer approach would be a more direct interaction with it, e.g. add a new constructor to Handler that initializes its internal state properly based on persisted state. This way it should be more safe if somebody decides to change Handler's internals. With the simulation approach, you risk ending in some undefined state (since it's not a full simulation - imagine someone add some more steps to protocol, or it buffers something internally, etc.). Using directly a new constructor assures you (kind of) that the Handler is in correct state after initialization.

[woocash2]

LGTM. Suggestion: consider implementing a more direct approach instead of simulation. I don't know how exactly your interactions with Handler will look like but in general a safer approach would be a more direct interaction with it, e.g. add a new constructor to Handler that initializes its internal state properly based on persisted state. This way it should be more safe if somebody decides to change Handler's internals. With the simulation approach, you risk ending in some undefined state (since it's not a full simulation - imagine someone add some more steps to protocol, or it buffers something internally, etc.). Using directly a new constructor assures you (kind of) that the Handler is in correct state after initialization.

I think it is possible. Our goal is to obtain a handler which witnessed some events in a particular order, and a Service with some of its IO channels partially filled, also depending on the sequence of events.

We can have Handler::new which creates the Handler in a particular state, and returns the sequence of messages to be passed to Service::new which will fill its channels itself.

That would be nicer indeed.

[timorl]

The exiting thing feels wrong, I suspect it should rather be an error propagated outwards, but I really don't want to make you rewrite this again so I guess it can stay.