[Doc] provider is arc'ed internally

[Dvisacker]

Component

provider, pubsub

What version of Alloy are you on?

alloy v0.11.1

Operating System

macOS (Apple Silicon)

Describe the bug

DynProvider in alloy v0.11.1 is really useful but I am having the following issue for functions that take Arc<P> where P: Provider as an argument.
In the example below changing provider: Arc<P> to provider: P fixes the problem but I am not sure that's ideal and many libraries have functions that require Arc<P>.

pub async fn get_token_balance<P: Provider>(
    provider: Arc<P>,
    token: Address,
    holder: Address,
) -> Result<U256> {
    let token = IERC20::new(token, provider.clone());
    let balance = token.balanceOf(holder).call().await?;
    Ok(balance._0)
}

DynProvider is a wrapper around an Arc but not directly an Arc and the functions above expects Arc<P> which results in a type mismatch.

pub struct DynProvider<N = Ethereum>(Arc<dyn Provider<N> + 'static>);

Perhaps adding a method like follows would help - I'm not sure -.

pub fn into_arc(self) -> Arc<dyn Provider> {
    self.0
}

[DaniPopes]

Generally requiring Arc<P> is more restrictive and it's a leftover from ethers' middleware. If you want to clone the P then just add a + Clone bound, otherwise just P should be used.

That said we can still add such a method but I would highly recommend you try dropping the extra Arc everywhere as all providers are internally Arc'd anyway too.

[Dvisacker]

Makes sense, I didn't know providers where arc'd internally. Then feel free to close the issue if you wish - as you say I think it can make sense to add a method as some libraries require arc<P> but not needed for me personally.