Extract EIP-3076 into its own crate

[michaelsproul]

The slashing_protection crate contains our implementation of EIP-3076. This implementation is used by the eth2 crate, which means we pull in all of slashing_protection, including its SQL-related stuff, as dependencies of eth2.

We should pull out the EIP-3076 related code into its own crate separate from slashing_protection, something like common/eip-3076.

Even when we split the eth2 crate into two separate crates (one generic in Bosun and one Lighthouse-specific in Lighthouse), we may want the EIP-3076 stuff in the generic crate, as it is a cross-client format. In this case we'd pull EIP-3076 into Bosun as well.

[michaelsproul]

cc @macladson / @hopinheimer this might be a nice small standalone one, the EIP-3076 stuff and slashing_protection don't change very often.

[nadtech-hub]

may I take this up?

[macladson]

@nadtech-hub go for it!
I had a look at implementing it earlier today and it looks like it'll be a little messy (particularly the error types and tests) so reach out if you need a hand

[nadtech-hub]

Sure mate, I'm still on it btw. I was overwhelmed for a while.

[nadtech-hub]

@michaelsproul any ideas how to fix cyclic dependencies?

[michaelsproul]

@nadtech-hub usually you can avoid cycles by isolating each logical feature/component

what's the cycle between currently? the eip3076 crate should not depend on slashing_protection (the other direction is fine though). and then eth2 should just depend on eip3076 and not slashing protection