Improve snowbridge pallet and relayer upstram

[ParthDesai]

• Try to add pruning to the pallet in order to make storage size bounded
  This will prevent the pallet to consume arbitrary amount of storage and data will have a fix upper bound. PR is opened here based on my commit: Bound finalized header, execution header and sync committee by RingBuffer and BoundedVec Snowfork/snowbridge#815
• Try to Improve relayer to have better reconstructed state upon restart
  Currently, if relayer is restarted, it does not start off from where it is left rather it recalculate and often time skips some headers. By having it reconstruct precise state upon restart, we can make sure that nothing is skipped.
• Depending upon outcomes, integrate changes either via fork or via updating reference

[vgeddes]

Hey @ParthDesai, I just wanted to discuss with you about your aims and timeline here, to improve collaboration.

We are busy refactoring our light client, see for example these PRs:

• Refactor verification of updates in beacon client Snowfork/snowbridge#835
• Initialize beacon light client from checkpoint Snowfork/snowbridge#828
• Refactor beacon client Snowfork/snowbridge#816

So I wouldn't advise forking off our light client right now, as you'll end up with obsolete code. We are still have more refactoring to do, and we estimate this will take another few weeks. For example:

• We will probably unify the sync_committee_period_update and import_finalized_header extrinsics to align more closely with the ALC spec, which will make the code easier to audit. The unified extrinsic will be capable of importing both sync committees and finalized headers.
• For import_execution_header, we actually no longer need to verify the sync committee aggregate signature, as we are already using ancestry proofs to verify the supplied execution header against an already imported finalized beacon header. So this should reduce the dispatch weight considerably, as BLS verification is expensive.
• Make sure there are no gaps between imported execution headers (we don't check for that currently)
• Improve our unit tests, by enabling minimal spec by default, and running minimal spec tests only. Its easier to generate mock data for the minimal spec.

[ParthDesai]

Hey @ParthDesai, I just wanted to discuss with you about your aims and timeline here, to improve collaboration.

We are busy refactoring our light client, see for example these PRs:

* [Refactor verification of updates in beacon client Snowfork/snowbridge#835](https://github.com/Snowfork/snowbridge/pull/835)

* [Initialize beacon light client from checkpoint Snowfork/snowbridge#828](https://github.com/Snowfork/snowbridge/pull/828)

* [Refactor beacon client Snowfork/snowbridge#816](https://github.com/Snowfork/snowbridge/pull/816)

So I wouldn't advise forking off our light client right now, as you'll end up with obsolete code. We are still have more refactoring to do, and we estimate this will take another few weeks. For example:

* We will probably unify the `sync_committee_period_update` and `import_finalized_header` extracts to align more closely with the ALC spec, which will make the code easier to audit. The unified extrinsic will be capable of importing both sync committees and finalized headers.

* For `import_execution_header`, we no longer need to verify the sync committee aggregate signature, as we can use ancestry proofs to verify the supplied execution header against an already imported finalized beacon header.

* Make sure there are no gaps between imported execution headers (we don't check for that currently)

* Improve our unit tests, by enabling minimal spec by default, and running minimal spec tests only. Its easier to generate mock data for the minimal spec.

Thank you @vgeddes for the update.

We did fork the light client earlier and combined both sync_committee_period_update and import_finalized_header among other things. But at the moment, we are referencing snowfork's version due to maintenance of obsolete code.
We will update our reference once refactor on your side is done.

Meanwhile, let me know if you need my help in improving the light client.

[vgeddes]

I think besides all the refactoring I described above, there's one more remaining issue which affects the light client.

Ethereum is getting hardforked for upgrades more frequently now. Like at least twice per year. So we need to ensure the light client is able to handle these upgrades seamlessly, preferably without storage upgrades, as those are a pain.

In practice this means the lightclient pallet needs to be able to accept LightClientUpdate updates that refer to either pre-upgrade and post-upgrade Ethereum state.

We are prototyping some ideas. For example, using versioned data structures. Particularly if those are going to put in storage:

enum VersionedBeaconHeader {
   V1(V1::BeaconHeader)
   V2(V2::BeaconHeader)
}

The problem is not straightforward, because with Ethereum, the consensus layer and execution layer can be upgraded separately. For example, in the upcoming Deneb upgrade, this field will be added to the execution payload: https://github.com/ChainSafe/lodestar/blob/f16192f079d68835f05feada7aff009c20ada963/packages/types/src/deneb/sszTypes.ts#L89

We need to think about the problem some more and would appreciate it if you have any thoughts.

[jfrank-summit]

no longer needed for now