Refactor Sandbox

[pgherveou]

This PR does the following refactoring, to prepare further update that will make it easier to integrate Drink with a Network of chains connected through XCM:

Specifically it does the following:

• Use generics instead of hard coded types, so we can adapt e2e tests to various runtimes
• Refactor Sandbox so that it can be used with runtime that do not implement contracts (such as a Relay chain Runtime for example)

For example token APIs only require the Sandbox to be generic over something that implement pallet_contracts

impl<R: pallet_balances::Config> Sandbox<R> {
    /// Add tokens to an account.
    ///
    /// # Arguments
    ///
    /// * `address` - The address of the account to add tokens to.
    /// * `amount` - The number of tokens to add.
    pub fn add_tokens(
        &mut self,
        address: AccountIdFor<R>,
        amount: BalanceOf<R>,
    ) -> Result<BalanceOf<R>, DispatchError> {
        self.execute_with(|| pallet_balances::Pallet::<R>::mint_into(&address, amount))
    }

    /// Add tokens to an account.
    ///
    /// # Arguments
    ///
    /// * `address` - The address of the account to add tokens to.
    /// * `amount` - The number of tokens to add.
    pub fn balance(&mut self, address: &AccountIdFor<R>) -> BalanceOf<R> {
        self.execute_with(|| pallet_balances::Pallet::<R>::free_balance(address))
    }
}

[pmikolajczyk41]

I love the direction of this changes, that would finally allow to work freely with any runtime, not only for contract purposes, but for general interaction as well

if I understand the intention correctly, the idea is that:

• Sandbox essentially wraps externalities and has a generic argument for a runtime, which can be actually anyhow configured
• depending on this generic argument, Sandbox enables pallet-specific operations, but not through traits (like ChainApi and ContractApi), but rather through generic bounds

is that so?

[pgherveou]

I love the direction of this changes, that would finally allow to work freely with any runtime, not only for contract purposes, but for general interaction as well

if I understand the intention correctly, the idea is that:

* `Sandbox` essentially wraps externalities and has a generic argument for a runtime, which can be actually anyhow configured

* depending on this generic argument, `Sandbox` enables pallet-specific operations, but not through traits (`like ChainApi` and `ContractApi`), but rather through generic bounds

is that so?

Yes. That's pretty much what Sandbox was doing already (as far as I understand).
I just moved the constraints around to make it more flexible and work with any Runtime as long as they implement the right config. We could re-introduce the traits and implement them for runtime that implement the right configs but I don't think it's necessary, simple generics bounds implementation should be enough here.

[pgherveou]

Addressed your comments

[pmikolajczyk41]

thank you very much for this contribution!

[deuszx]

I think it's a regression that users now have to even know about the Sandbox. It was supposed to be a low-level object and developers use high-level session.

[pgherveou]

yeah right this is indeed a bit confusing without the "mocking_api" name
will update

[deuszx]

It's not only about the name - name is just a "gate" into the Sandbox world. Of course, we can't stop users from using it, if they want, but I think the API should lead developer through the path of least resistance and suggest usage of simple constructs.

I'd prefer to leave the previous approach, if possible.

[pgherveou]

I think the issue here is that the mock utilities should not be tied to the Sandbox struct.
I restored the API and moved these props to the session in the last commit.
lmk what you think

[deuszx]

Looks good, thanks :)

[pgherveou]

@deuszx @pmikolajczyk41 not sure what kind of approval is required to trigger CI here, you mind re-approving so we can merge this asap?