Add support for P<>K bridge

[green-jay]

Goal:
Allow simulating transactions between Polkadot<>Kusama

[xlc]

related #695 #681

[xlc]

Here is an example tx from mainnet that could be used for testing purpose:
Source @ Asset Hub Kusama: https://assethub-kusama.subscan.io/block/7144107
Relayed @ Bridge Hub Kusama: https://bridgehub-kusama.subscan.io/block/3481382?tab=event
Received @ Bridge Hub Polkadot: https://bridgehub-polkadot.subscan.io/block/2764368?tab=extrinsic
Dest @ Asset Hub Polkadot: https://assethub-polkadot.subscan.io/block/6445172?tab=event&event=6445172-1

The bridge message pallet requires proof for relayed messages and I don't think we can easily spoof it without modify the upstream code. However, what it does eventually is to just dispatch some XCM, which we maybe able to do without using the bridge message pallet.

So the work that needs to be done are:

• Detect bridge events BridgeKusamaMessages.MessagesAccepted / BridgePolkadotMessages.MessagesAccepted
• Take the XCM out somehow
• Identify the dest parachain
• Dispatch the XCM somehow on dest bridge hub???
• Profit

[bkontur]

* Detect bridge events `BridgeKusamaMessages.MessagesAccepted` / `BridgePolkadotMessages.MessagesAccepted`

* Take the XCM out somehow

* Identify the dest parachain

* Dispatch the XCM somehow on dest bridge hub???

The message should be stored in the bridge message queue as encoded bytes: https://github.com/paritytech/polkadot-sdk/blob/master/polkadot/xcm/xcm-builder/src/universal_exports.rs#L381-L387.
But I think if we by-pass the real relay (message proofs) and "directly" trigger XCM dispatch on the dest BH, we won't test the real transport, which is also important here.

[bkontur]

for by-passing, it should be possible to read XCM on the source BH: OutboundLanes and OutboundMessages

but not sure how to by-pass everything, maybe trigger XCM dispatch on the target BH with DMP/HRMP either enqueue_inbound_downward_messages or 'enqueue_inbound_horizontal_messages' - prepare some "valid" storage data with set_storage or set_validation_data or whatever

[xlc]

we can inject DMP/HRMP to the target BH but unsure if we can mimic the exact same XCM behaviour compare to dispatched by the message pallet

[xlc]

blocked by paritytech/polkadot-sdk#4793

[green-jay]

hello, any ETA on this? we would like to E2E test Kusama root track bridging to Hydration on Polkadot