feat(node_framework): Support for preconditions and oneshot tasks

[popzxc]

This PR consists of three parts in one (sorry for that).

Part 1. Preconditions

An alternative take on #1290

In short:

• Adds two new concepts to the framework: Precondition and UnconstrainedTask.
• Any precondition is a future that must successfully resolve before tasks can be started. An example of future precondition may be the readiness of storage after snapshot sync.
• Any Task will wait until all of the added preconditions successfully resolves.
• An UnconstrainedTask is a way to opt-out from waiting for preconditions to complete. These may be useful in two cases:
  • If you have a stateless component that should start ASAP (e.g. healthcheck server).
  • If your task is supposed to ensure that precondition is met (e.g. task that does state recovery).

The last point is important, btw: imagine that the node runs as a set of microservices on different machines. The precondition should be present on all machines (e.g. simply wait until it's ensured), but the corresponding unconstrained task should be run on just one machine (since it alters state).

In the current impl there is no way to subscribe to a certain set of preconditions or opt-out from a single precondition. You either have to wait for them all or may rely on none. This is done on purpose to not overcomplicate the publicly facing interface. The expectation is that Task is a working default that people may just pick up and it'll be guaranteed to work. You only need to meet extra complexity when a Task is not enough for you.

Part 2. Oneshot tasks

Adds a notion of oneshot tasks and adds support of running the service in an oneshot mode (e.g. when we only add oneshot tasks and expect the node to exit as soon as all of them resolve).

It comes in two flavors:

• OneshotTask. An oneshot analog of Task.
• UnconstrainedOneshotTask. An oneshot analog of UnconstrainedTask. May be useful, for example, to enforce some Precondition and then exit.

This way the logical flow of the node is as follows:

1. Start all the unconstrained tasks, unconstrained oneshot tasks, and preconditions.
2. Wait for all the preconditions to resolve.
3. Start all the tasks and oneshot tasks.
4. Wait for any of long-running tasks (i.e. not oneshot) to exit.

Part 3. Refactoring

There was a lot of new logic added, so the ZkSyncService::run became pretty messy.
The most notable part here is that now all flavors of tasks are managed by the new Runnables collection that encapsulates the logic of turning different tasks into futures that can be launched by the service.

[slowli]

Conceptually looks good. I wonder whether it could make sense to generalize preconditions to oneshot tasks that could be used for programmatic migrations etc. Can be done later, obviously.

[popzxc]

I wonder whether it could make sense to generalize preconditions to oneshot tasks that could be used for programmatic migrations etc. Can be done later, obviously.

@slowli Yup, that's exactly my plan, but indeed I want to tackle it in a separate PR.

[popzxc]

@slowli I'm going to merge this to not block any further progress, but if you have any comments -- I'll be happy to work on them in follow-up PRs.