Improve async processing and error handling

[therustmonk]

@mskrzypkows Here is the PR for your #23

I've added some important improvements that help to to keep the code easy to maintain. In Rust, it's easy to open a branch of hell, so it's important to give the compiler everything that can be explicitly undeclared for now.

The PR:

• avoids using thiserror, it's the main tempter :) prefer using anyhow as long as possible
• avoids spawning tokio thread (try to use a single processing routine), separate couroutines are extremelly challenging to debug. I took the risk again in SFFL and agreed to prematurely spawn coroutines, and I still regret it 😢 Use a single coroutine with a sequence of operations. Don't worry about performance now.

The best Rust development flow is to follow the steps:
Easy and Compact Implementation -> Intensive Refactoring -> Optimization

I don't mind these things, we will need them, but they are more like decoration. For now, let's bake the cake first 🍰
I refactored the code but haven't tested it. Could you please check it?

[mskrzypkows]

Why do you prefer anyhow? We've been using thiserror in dkg-proto, and it was fine for descriptive errors.

Regarding the tokio::spawn, I know what you mean, I've been working a lot of with threads in C++ and have some experience with debugging concurrent software.
We can start with a self.node_rx.try_recv() but need to be aware of starvation problem, the self.main_block_preconfirmation_step().await?; may be run less frequent when there are a lot of incoming messages.
Have you seen this: https://www.notion.so/nethermind/AVS-Node-Software-Diagrams-df0105a1d3f54276b8b9cbd2f2a5a101 ?

[mskrzypkows]

Why not tracing::error?

[therustmonk]

Yeah, correct, it has to be error! 👍

[mskrzypkows]

I've checked locally, works 👍

[smartprogrammer93]

@therustmonk Thank you sir