chore: switch to unstable lighthouse and update dependencies

[dknopik]

Proposed Changes

Everything we had in our Lighthouse anchor branch is finally merged into their unstable 🥳

Switch to specifying branch = "unstable" on our lighthouse dependencies. Note that the specific commit is still pinned by Cargo.lock, so it will not ever spontaneously break (but might if cargo update is called).

Also, update all our dependencies.

Additional Info

Intentionally targets unstable to avoid risking some bug.

This breaks the blsful feature on bls_lagrange due to an accidental breaking change on a transitive dependency. Hopefully this is fixed upstream soon, but I am willing to accept this right now as we do not use that anyway.

[Zacholme7]

Do we need to keep the blsful related code if it is not used? Or is it planned to be used in the future

[diegomrsantos]

I'm wondering what we would do when merging Anchor to stable. We can't just change LH to stable, as there's no guarantee it's gonna work. So, should we use LH stable all the time?

[dknopik]

Do we need to keep the blsful related code if it is not used? Or is it planned to be used in the future

right now it is just around for reference, or if someone wants to compile a version without unsafe, but IMO it can be removed.

[dknopik]

I'm wondering what we would do when merging Anchor to stable. We can't just change LH to stable, as there's no guarantee it's gonna work. So, should we use LH stable all the time?

Right now, we can't use stable. IMO there is no special step to be taken when we merge to stable, as we want to use the same version as during development to ensure compatibility

[diegomrsantos]

I'm wondering what we would do when merging Anchor to stable. We can't just change LH to stable, as there's no guarantee it's gonna work. So, should we use LH stable all the time?

Right now, we can't use stable. IMO there is no special step to be taken when we merge to stable, as we want to use the same version as during development to ensure compatibility

But seems reasonable that we should use stable LH in general, right? It's just another dependency as any other, perhaps even more important. So we shouldn't be using an unreleased, in-development version of it, should we?

[dknopik]

But seems reasonable that we should use stable LH in general, right? It's just another dependency as any other, perhaps even more important. So we shouldn't be using an unreleased, in-development version of it, should we?

Lighthouse is primarily an application. Releases in their sense do not really apply to internal crates (also w.r.t. compatibility and testing). In other words, they test lighthouse as a full application, and stable refers to that. Therefore I am not too bothered with using unstable, especially if it contains features we require, as we do right now and might in the future. That being said, it seems reasonable to switch to "stable" once that has all the things we need, but would not make it policy that it HAS to be stable.

[mergify]

This pull request has merge conflicts. Could you please resolve them @dknopik? 🙏

[diegomrsantos]

We agreed to use a fixed commit in the unstable branch while the changes we need aren't in stable.

[dknopik]

@diegomrsantos done, wdyt?

[diegomrsantos]

Should this be done in this PR?

[dknopik]

It does not compile otherwise

[dknopik]

I can has? :(