XCM Generics Benchmarks Leftovers (TODO)

[shawntabrizi]

From: paritytech/polkadot#3940

• Is there a better way to verify that tranasct XCM completed successfully? Potentially set some unique storage via the extrinsic and check that storage? (without root?)

} verify {
	// TODO make better assertion?
	let num_events2 = frame_system::Pallet::<T>::events().len();
	assert_eq!(num_events + 1, num_events2);
}

• Add an inspect function to XcmSender to allow us to verify the message is queued correctly?

	initiate_reserve_withdraw {
		let holding = worst_case_holding();
		let assets: MultiAssets = holding.clone().into();
		let assets_filter = MultiAssetFilter::Definite(assets);
		let reserve = T::valid_destination().map_err(|_| BenchmarkError::Skip)?;
		let mut executor = new_executor::<T>(Default::default());
		executor.holding = holding;
		let instruction = Instruction::InitiateReserveWithdraw { assets: assets_filter, reserve, xcm: Xcm(vec![]) };
		let xcm = Xcm(vec![instruction]);
	}:{
		executor.execute(xcm)?;
	} verify {
		// The execute completing successfully is as good as we can check.
		// TODO: Potentially add new trait to XcmSender to detect a queued outgoing message.
	}

• Use MAX_ASSETS limit from the XcmExecutor to generate a worst case message with a maximum number of assets. Needs XCM v3 I believe

	// Worst case scenario for this benchmark is a large number of assets to
	// filter through the reserve.
	reserve_asset_deposited {
		const MAX_ASSETS: u32 = 100; // TODO when executor has a built in limit, use it here. paritytech/polkadot-sdk#900