feat: Replace FeltRng trait object in ClientBuilder and Client with generic

[sergerad]

Context

Relates to #849.

We have various trait objects in our stack that cause Send/Sync problems downstream.

One such trait object is the Box<dyn FeltRng> used by Client and ClientBuilder.

We also hand roll ClientRng(Box<dyn FeltRng>) for a reason that eludes me at the moment. In any case its not required when moving to generics AFAICT.

Changes

• Replace Box<dyn FeltRng> with generics.
• Delete ClientRng.

Future Work

Consider moving the remaining trait objects of the Client struct to generics.

• store: Arc<dyn Store>
• rpc_api: Arc<dyn NodeRpcClient + Send>
• authenticator: Option<Arc<dyn TransactionAuthenticator>>

[sergerad]

Oddly the docs already had an example without Box<>. So did not need to change docs/src/library.md for example.

[sergerad]

Would be nice to do away with this by requiring the R to be supplied during the build fn. But wasn't sure people would prefer those ergonomics.

[tomyrd]

We also hand roll ClientRng(Box) for a reason that eludes me at the moment. In any case its not required when moving to generics AFAICT.

Generics was the old way we used to do it but it was removed here.

I think I prefer the trait object approach but it's totally subjective.
CCing @igamigo @bobbinth for their opinion.

In any case we should be consistent, so if we want to go with the generics route we should also change the other trait objects. If we wanted to keep trait objects could we add + Sync to the ClientRng?

[igamigo]

We briefly discussed deferring this to the next release, mainly for making these changes cohesively and see how the requirements change with the upcoming VM API refactors.

[vakochetkov]

Hi, @igamigo! Are there any plans to merge this PR? It would be much easier if we had the ability to use MidenClient in async Send + Sync contexts or at least Send + Mutex, e.g., with the Tokio runtime.