Use spawn_blocking when processing synedrion messages

[ameba23]

This was suggested by @fjarri here:

entropyxyz/manul#91 (comment)

Since synedrion's message processing methods are synchronous and computationally heavy, it does not make sense to run them in async tokio tasks as this may prevent the executor from moving other tasks forward.

This PR uses tokio::task::spawn_blocking to run them as blocking, syncronous tasks instead.

Unfortunately this does not appear to give any improvement in performance when testing signing with 8 parties.

Since we will be soon swapping this out for the protocol execution loop provided by manul, it probably makes no difference whether or not we merge this. But gonna put it up anyway.

[ameba23]

Here we have the issue that the channel is async but we are now in a sync block. However because tx.send is likely to be considerably faster than session.process_message, i think it still makes sense to do this.

The alternative would be to use std::sync::mpsc rather than tokio::sync::mpsc, but then we have the problem that we can't use the receiver with tokio::select!.

[HCastano]

I don't really know what's going on behind the scenes in the protocol session code, but from the spawn_blocking link you provided it mentions that if the workload is CPU bound we could benefit from using something like Rayon.

Maybe worth looking into in a different PR.

[fjarri]

I am not sure rayon would fit naturally here since we need to create new tasks and add them to the pool as we receive messages. But maybe it allows that too. In any case, in my tests spawn_blocking works well enough.