chore: move post-merge code from protos to forrestrie

[suchapalaver]

BACK-99

Since our first aim is a library for verifying pre-merge Ethereum data we want to separate out post-merge code for now. The main overlap is in firehose-protos where we compile the protobuffer for Beacon blocks and implement conversion methods on it. This PR moves that code to forrestrie - our library for post-merge PoC work.

Now, forrestrie and firehose-client are the only crates with post-merge code. Further work should remove them from publishing processes.

PS: when using cargo-udeps to detect unused dependencies I found a few unrelated to this work as well, hence the random dependency deletions.

[linear]

BACK-99 Move post-merge code and protobuffer out of `firehose-protos` to `forrestrie`

joseph said in BACK-98:

I propose dealing with the coupling issues we have. Since we're working on pre-merge first I think the easiest way to tackle this is to remove the post-merge code from firehose-protos. Put it in forrestrie for now, and then when we publish on crates.io we just publish the pre-merge crates, no forrestrie, no firehose-client.

[anirudh2]

Question. I don't mind this, but if we're okay with this, why wouldn't we just refactor firehose-protos out of existence too? I know you'd mentioned this possibility before @suchapalaver.

[suchapalaver]

Question. I don't mind this, but if we're okay with this, why wouldn't we just refactor firehose-protos out of existence too? I know you'd mentioned this possibility before @suchapalaver.

Now, as opposed to when I said that, we have a monorepo rather than separate crates all with their own sets of dependencies. We have more than one crate pulling in the conversion methods for Ethereum blocks, so I say we keep firehose-protos. Otherwise, it would mean duplicating the conversion methods in each respective crate. Rust's orphan rule means we can't implement those methods outside of the crate where the protobuffers are compiled.

[anirudh2]

Please change your chore commit to refactor

[anirudh2]

Question. I don't mind this, but if we're okay with this, why wouldn't we just refactor firehose-protos out of existence too? I know you'd mentioned this possibility before @suchapalaver.

Now, as opposed to when I said that, we have a monorepo rather than separate crates all with their own sets of dependencies. We have more than one crate pulling in the conversion methods for Ethereum blocks, so I say we keep firehose-protos. Otherwise, it would mean duplicating the conversion methods in each respective crate. Rust's orphan rule means we can't implement those methods outside of the crate where the protobuffers are compiled.

When we bring post merge into prod, would we undo this refactor?

[suchapalaver]

Question. I don't mind this, but if we're okay with this, why wouldn't we just refactor firehose-protos out of existence too? I know you'd mentioned this possibility before @suchapalaver.

Now, as opposed to when I said that, we have a monorepo rather than separate crates all with their own sets of dependencies. We have more than one crate pulling in the conversion methods for Ethereum blocks, so I say we keep firehose-protos. Otherwise, it would mean duplicating the conversion methods in each respective crate. Rust's orphan rule means we can't implement those methods outside of the crate where the protobuffers are compiled.

When we bring post merge into prod, would we undo this refactor?

Possibly! I guess we see where we are at that point? I expect with the various refactorings and cleaning up that we anticipate in header-accumulator et al it would be a pretty gnarly reversion!

[suchapalaver]

Question. I don't mind this, but if we're okay with this, why wouldn't we just refactor firehose-protos out of existence too? I know you'd mentioned this possibility before @suchapalaver.

Now, as opposed to when I said that, we have a monorepo rather than separate crates all with their own sets of dependencies. We have more than one crate pulling in the conversion methods for Ethereum blocks, so I say we keep firehose-protos. Otherwise, it would mean duplicating the conversion methods in each respective crate. Rust's orphan rule means we can't implement those methods outside of the crate where the protobuffers are compiled.

When we bring post merge into prod, would we undo this refactor?

Possibly! I guess we see where we are at that point? I expect with the various refactorings and cleaning up that we anticipate in header-accumulator et al it would be a pretty gnarly reversion!

@anirudh2, what are your thoughts?

[anirudh2]

Alright. I guess we can leave it as a future us problem given that's what we're doing with the rest of post-merge.