Fix bridge hub router

[yrong]

Context

Currently for sending Ethereum asset by reserve_transfer_assets to work it requires to explicitly set xcm version of Ethereum Location on Assethub, e.g.

polkadot-sdk/cumulus/parachains/integration-tests/emulated/tests/bridges/bridge-hub-rococo/src/tests/snowbridge.rs

Lines 391 to 394 in 68ab248

	AssetHubRococo::force_xcm_version(
	Location::new(2, [GlobalConsensus(Ethereum { chain_id: CHAIN_ID })]),
	XCM_VERSION,
	);

Actually this is unnessessary, IMO setting xcm version of Ethereum only make sense on BridgeHub to construct different Command to execute on Ethereum when there is xcm version specific logic on solidity side.

It seems more like a bug introduced by bridge-hub-router, more details in #140 (comment)

[yrong]

It should not throw the DestinationUnsupported error here, instead as required by Tuple::validate logic

polkadot-sdk/polkadot/xcm/src/v4/traits.rs

Lines 264 to 270 in 67b7d64

	match Tuple::validate(destination, message) {
	Err(SendError::NotApplicable) => None,
	Err(e) => { return Err(e) },
	Ok((v, c)) => {
	maybe_cost = Some(c);
	Some(v)
	},

, the implementation of SendXcm should only throw the error NotApplicable to give chance to the next impl of the SendXcm Tuple to process.

[claravanstaden]

Good catch!

[yrong]

From the log integration test send_xcm_through_opened_lane_with_different_xcm_version_on_hops_works failed so this PR may introduce some side effects.

So just stop here until the issue confirmed by Parity team.

[yrong]

Closed in favor of paritytech#4162