fix: remove ibc specific logic

[chatton]

Overview

I noticed some odd behaviour when attempting to manually test this with a local multi chain setup and hermes.

I saw the "ibc" specific path was not actually enabled (while IBC was enabled, the migration module was not being provided with the store key)

I dug in a little more, and realised the bare minimum requirement for ibc to continue to function, is to have a MsgUpdateClient submitted at H + 1 where H is the migration height.

This will be the transition from N -> 1 validator, and then all future ibc transactions are accompanied by a MsgUpdateClient.

I confirmed that the test fails with failed to verify header: cant trust new val set: invalid commit -- insufficient voting power: got 5, needed more than 8 if trying to only update H + 2 or anything afterwards. There is no need to spam MsgTransfers or to perform more than a single MsgUpdateClient

This means we can also completely remove the special handling for ibc and perform the migration the same way no matter what, the only important thing is MsgUpdateClient at height H+1

[damiannolan]

Aligns with the write up I had in https://hackmd.io/@damian666/HkCWLNNs1g and makes sense to me. Nice to finally see this put into action.

Key part being the lightclient update at H + 1 as this is where the header reflects trusted validators and they have signed NextValsHash = SequencerKey. Subsequently at H + 2 the sequencer key is the only active validator in the set.