Service manager

[adzialocha]

Introduces ServiceManager which orchestrates long-running concurrent services with a communication bus between them. Also it kindly informs all services about a shutdown and waits for them to stop before quitting the process for good.

The next step will be to a) remove TaskManager and replace it with this in the Runtime b) refactor the GraphQL API to fit the new "service" API and move it into the manager. c) Make use of the axum graceful shutdown feature.

Later we will also add the "Materializer" with the worker as a service here and use the communication bus to inform it about new, incoming entries from the GraphQL API. Much later the Replication service will also live here ..

Closes: #86 and #84

📋 Checklist

• Add tests that cover your changes
• Add this PR to the Unreleased section in CHANGELOG.md
• Link this PR to any issues it closes
• New files contain a SPDX license header

[sandreae]

Looks really good to me. One thing I wondered is do we need to be able to get any more info from the service_manager about the state of the spawned services? I tried writing a test which had one service which completed it's job then stops, and I wanted to check the status of all services from the manager side, but this isn't possible now. Maybe it isn't something we need, but I just wondered. I approve of it greatly as it is now in any case, it has a nice simple API :-)

[adzialocha]

Looks really good to me. One thing I wondered is do we need to be able to get any more info from the service_manager about the state of the spawned services? I tried writing a test which had one service which completed it's job then stops, and I wanted to check the status of all services from the manager side, but this isn't possible now. Maybe it isn't something we need, but I just wondered. I approve of it greatly as it is now in any case, it has a nice simple API :-)

Nice, thanks!

The manager will be used for services which will run as long as the whole program runs, at least for now, this is why I didn't add any more functionality in that direction. What would make sense though is to crash the whole program as soon as one service panicks (fitting the "all services or nothing" notion).

I would like to add this though in a more real-life pr, when integrating the http server and materializer, it will also need touches in the worker for propagating up the errors. Think there is an issue for that 👍