Xcm emulator nits

[bkontur]

Desription

Summary

This PR introduces several nits and tweaks to xcm emulator tests for system parachains.

Explanation

Deduplicate XcmPallet::send( with root origin code

• Introduced send_transact_to_parachain which could be easily reuse for scenarios like governance call from relay chain to parachain.

Refactor send_transact_sudo_from_relay_to_system_para_works

• Test covered just one use-case which was moved to the do_force_create_asset_from_relay_to_system_para, so now we can extend this test with more governance-like senarios.
• Renamed to send_transact_as_superuser_from_relay_to_system_para_works.

Remove send_transact_native_from_relay_to_system_para_fails test

• This test and/or description is kind of misleading, because system paras support Native from relay chain by RelayChainAsNative with correct xcm origin.
• It tested only sending on relay chain which should go directly to the relay chain unit-tests (does not even need to be in xcm emulator level).

Future directions

Check restructure parachains integration tests issue and PR with more TODOs.

[NachoPal]

Why are we assuming that is going to be always root? Someone would like to test sending a Transact with different origin. I think we should either accept origin as an extra argument for send_transact_to_parachain or rename method to send_transact_to_parachain_as_sudo (better the first option)

[bkontur]

Well, this is meant for governance-like calls from relay to para with RuntimeOrigin::root() and UnpaidExecution not to repeat the same code everywhere:

/// A root origin (as governance) sends `xcm::Transact` with encoded `call` to child parachain.

If we want it make it more general, then yes origin and also some "switch" for UnpaidExecution/BuyExecution wrapper should be added as a parameter. Then we should add it as a generic helper function for Chain trait.

I think, for me, send_transact_to_parachain_as_sudo means more like there is pallet_sudo which is not the case.

I am inclined to keep it as it is :).
Anyway, anybody else can still create whatever scenario with [<$chain Pallet>]>::XcmPallet::send.

@NachoPal wdyt?

[NachoPal]

Didn't realise about the hardcoded UnpaidExcution. Are there cases where an UnpaidExecution is going to work with a different origin than Superuser? If not then I do not see it necessary to have it as function argument.

Sorry, I sometimes use sudo and root interchangeably. If it is meant to be for governance-like calls (root) then we can do:

pub fn send_transact_to_parachain_as_root(
					recipient: $crate::impls::ParaId,
					call: $crate::impls::DoubleEncoded<()>
				)

What I am trying to avoid is to impl a method that is only meant to work for root, UnpaidExecution and Origin::Superuser with a so generic name - send_transact_to_parachain - (even if it is properly documented)

[bkontur]

ok, I renamed to send_unpaid_transact_to_parachain_as_root, please, check here: c30119c
I also was able to reuse do_force_create_asset_from_relay_as_root for force_create_and_mint_asset, which looks also much clear now

[NachoPal]

Just small nit to keep consistent with naming

[seadanda]

LGTM