Revert splitting of Moonbeam receiver contract

[ebma]

Context

To work around issues introduced by the increase in gas cost on Moonbeam, the receiver contract was split into two parts for https://github.com/pendulum-chain/vortex/issues/137, resulting in additional overhead on the frontend application.

It seems like squidrouter managed to deploy a fix that works around this issue and the original logic would work again. To reduce the overhead, the splitting of the receiver contract should get reverted.

TODO

• Add changes to allow the execution with either the automatic forwarding or the split receiver contract. When re-adding the logic for the automatic forwarding, point to the old receiver contract 0x066d12e8f155c87a87d9db96eac0594e872c16b2, more info here.
• Add a simple boolean flag to a config (either hardcoded or supplied via env variable) that defines which approach should be used.
• Test that the 'old' logic works

[ebma]

@pendulum-chain/product this change will also speed up the offramping process.

[ebma]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @gianfra-t @Sharqiewicz @TorstenStueber

[TorstenStueber]

We should probably also test what Squidrouter did in the mean time. Do they really respect the estimatedGas parameters? Can we change this in the future if we need to (e.g., if Moonbeam changes their weight settings again?)

[gianfra-t]

I would personally leave the code around. Not as an automatic fallback since that would be quite a lot of work for a very unlikely scenario, but such that it's easy to plug the "new" logic back.

[TorstenStueber]

@gianfra-t so the suggestion would be to have a config parameter that determines what option we want to use? Could make sense that way.

[ebma]

Good point, I changed the description to reflect that.

[vadaynujra]

@ebma @TorstenStueber, Will the reduction of the overhead as a result of this change result in the off-ramp becoming quicker for the user? By how much would this change quicken flow?

[TorstenStueber]

Yes. About 10-20 seconds.

[prayagd]

@vadaynujra moved this ticket to being prepared in the light of current priority