Create a dedicated ssv_types crate.

[Zacholme7]

Issue Addressed

N/A

Proposed Changes

This PR starts a ssv_types crate within anchor/common. It contains core SSV types in accordance with the spec. It does not contain related methods as we still need to determine what is needed, but just having these types defined helps. Validator related types are imported via the types crate in lighthouse.

Additional Info

This is just an initial draft to get the ball rolling. It will change as we see fit. Also waiting on re-export of ValidatorIndex in lighthouse into unstable.

[AgeManning]

Nice! I had a few comments

[AgeManning]

If we are using RSA, we probably should use a specific library and its associated public key type.

Each library will have an RSAPublicKey struct. This object will have been verified when created or deserialized. If we use this type, then there is no chance that we are carrying around invalid/malicious bytes in other types.

I think we want to deserialize any public key we get from the network instantly or reject the message, then we carry around only verified and valid keys throughout our types.

i.e our types shouldn't really be bytes anywhere, unless we have to have them.

[Zacholme7]

Follow up from internal message. Pulled in the rsa crate. We are facing a decoding issue as the public key is formatted as a PKCS#8 key but is wrapped in a PKCS#1 header. If the header matched the key, we would be able to decode this fine but the rsa crate rejects the decoding as the header does not match the underlying key. The options to fix this is to replace the header as I have implemented, or I believe you can strip it and then parse the key. Thoughts on this approach?

[AgeManning]

Replacing the header I think is the way to go, as an interop compatibility layer. In the future if they decide to move to be compliant we can just remove the interop layer (i.e replacing the header)

[jking-aus]

good work but I think we'll go with your other idea -- closing this pr