Implement initial context catchup

[fbozic]

Currently, the node performs catch-up in case of missing prior_hash upon receiving Transaction, or in case of TransactionRejection from the coordinator. The catch-up process is a blocking process by design on both sides (client and server).

Our first attempt to perform an initial catch-up upon receiving the Subscribed event led to a bunch of timeouts because when multiple nodes are started at the same time they try to perform catch-up at the same time, reference: https://github.com/calimero-network/core/blob/dd01008cd8a7352b1c417d5b56289f1e3f079250/crates/node/src/lib.rs#L578-L596

Initial ideas to tackle this issue:

• Setup interval tick event in the main control loop, pick one random pending context and perform catchup. This interval tick should ideally be random as well because if we start N nodes at the same time with the same interval we will end up with timeouts again.
• Make the server part of the catch-up process non-blocking. E.g. define the maximum number of streams node/network accepts and processes in parallel. For a new incoming stream that exceeds a maximum number of streams, we could send a new message variant indicating that the peer is already serving catch-up data and is not willing to accept a new stream. Keep in mind that we need to access ContextManager, Store, NetworkClient (due to config), and TxPool (this one might require extra care) from the catch-up reply task.

[fbozic]

Initial estimation: ~1 week

[fbozic]

We decided to go with simple delayed tokio::time::interval_at as the initial implementation. The delay value will be generated randomly during configuration creation.

cc @MatejVukosav @miraclx