overhead is minimal/nothing. waiting on @vgeddes to share comments before merging though.

We'll likely want something like this in future. Right now though, I think its a bit premature to add this functionality to our E2E stack.

In the short term (milestone V1), this testing feature will likely not be used at all, as its more straightforward to test simple XCM asset transfers using polkadot-launch parachain/config-xcmp.json. No need to run the relayer, and deploy contracts, etc. It also gives us more flexibility to customize parachain code/config for testing different XCM scenarios, instead of the structure mandated by the E2E stack.

Then in the longer term, as we evolve XCM and bridge messaging, the solution implemented in this PR won't be sufficient. Instead of a running an duplicate of our parachain, we'll need to run a custom parachain with pallets and config that differs from snowbridge.

@vgeddes we need to be able to test xcm e2e, including from the frontend. i don't really see much issue with adding this to our e2e stack. it will be used and the additional is pretty minimal. plz review based on the assumption that this is required.

can put it in a different script if u prefer but i think an e2e script with both is still important

@vgeddes this is actually needed to test basic functionality of the grandpa light client properly when testing the parachain merkle proofs as the merkle tree should be tested with more than 1 leaf.

i've also updated the script to take an argument "duplicate" such that it will run 1 parachain without the arg and 2 duplicated parachains with it, so should still be compatible with your needs for xcm testing/manually running a second parachain :)

e2e tests all pass in both configurations, with 2 or 3 chains running fine in each configuration, so going to merge

Cool, sounds good. On a related note, in #417 we're also gonna have to run at least 2 collators per parachain due to a change in block authoring logic in Cumulus.