Better manage computationally-heavy operations

[pdyraga]

The client needs to generate pre-parameters for threshold ECDSA key generation. This is a computationally-heavy operation that affects the rest of the client. When testing locally, we observed the Keep client disconnecting from other Keep clients and even disconnecting from Ethereum node. Limiting the concurrency level for TSS pre-param generation improves the situation slightly but it is still not solving the problem.

Keep client, most of the time, does not require a lot of CPU cycles:

• beacon DKG happens every 2 weeks,
• relay entry happens every week,
• ECDSA DKG happens every week,
• sweep happens every 8 hours,
• redemption happens every 8 hours.

(Note that the schedule of these operations is more aggressive for testnet.)

Here is an idea that can hopefully solve this problem:

• [x] We can introduce an abstraction to manage the lifecycle of computationally-heavy operations. Such operations should be paused when the Keep client is executing any of the protocols listed above.
• [ ] The pre-params pool should be persisted on disk to survive client restarts.
• [ ] We should require the client to generate a sufficient number of pre-parameters before joining ECDSA sortition pool.
• [ ] We should have a pause of a few blocks between potential ECDSA DKG re-tries to let the miner generate TSS params and re-fill the pool.
• [x] We should significantly increase the target size of pre-params pool.
• [x] We should potentially add a delay between pre-param generation iterations to not starve other processes of the client.