delayedack should validate ibc client state against latest rollapp committed state

[omritoptix]

Besides given us the gurantee that we only accept packets after a sequencer committed to it on the hub (i.e non-trusted sequencer assumption), it also protects us from a potential failure (non-malicious) where ibc transferes from rollapp to hub are processed before state committed and the blocks could potentially get lost. Assume the following scenario:

1. Sequencer writes block 100, 101
2. Block 100 has ibc tx
3. Sequencer doesn’t submit block 100,101 to DA or gossips them and blocks are deleted (due to bug)
4. Relayer relies block 101 with proof to the hub
5. Block 100,101 are accidentally deleted before sequencer managed to gossip or write to DA (due to bug)

the "hacky" solution for now is just to make sure relayers are only connected to full nodes (and not to the sequencer) so at least we know the block was already gossiped to the network.

Long term solution (besides the obvious maliciuos behavior a sequencer can perform) would be to validate against latest committed state of the sequencer.

This has the obvious downside of making ibc transfers wait until the sequencer committed the state which could take an order of dozens of seconds.

[omritoptix]

As discussed with @yishay-dym , we're gonna handle it optimistically to not hurt UX.
so basically the general idea is to accept the headers optimistically and in case of mismatch after the fact handle it.

Will probably require ADR.