Mitigate XCM RPC node unresponsiveness

[tomjeatt]

@bvotteler Dom's suggestion is to switch to using the repo we forked from for our xcm bridge. I'm not entirely sure what that means—could you add some details to the ticket?

Some of this work will be done on the UI, so that unresponsiveness XCM channels are disabled individually rather than blocking the bridge from loading.

[bvotteler]

@tomjeatt that suggestion to move back to the upstream wasn't so much about RPC responsiveness, but rather to reduce the repos we maintain.

So, the suggestion was to merge the additional configurations we made back on our fork back upstream so we can use that package. We initially needed the own fork to be able to upgrade to newer polkadot dependencies sooner than it took for upstream to be ready. With longer update/release cycles that isn't an issue anymore.

The downside is that we then need to limit the potential paths to show on the UI as upstream has many more potential routes configured, many of which we don't need to show in our UI.

[tomjeatt]

Limiting the paths shouldn't be too much of a headache—we already configure the UI to only load specific channels, we can extend that to only show specific currencies for each of those channels.

(If I've understood the problem correctly).

Let's have a catch up on Monday, think we might want to separate out these pieces of work (i.e. mitigating the RPC unresponsiveness which I'm beginning to think can only be done in the UI, and merging our fork back into the upstream repo).

[bvotteler]

Update: I opened the upstream PR: polkawallet-io#121
Awaiting review, feedback, change requests.

I'm also starting to work on reviewing our chopsticks test strategy. At the very least we'll need some changes, but I'm also investigating if we can skip some of them to rather validate hard-coded configs with on-chain data and/or data from subscan if possible.

[bvotteler]

Update: Our PR has been merged and released as part of @polkawallet/bridge v0.1.5