feat(sidecar): ERC-2335 Keystore signer

[thedevbirb]

Closes #283. This PR introduces support for running the sidecar by reading the private keys from ERC-2335 keystore files.

Such keystore are expected to be placed inside the keys folder of this project which reserved for this purpose only. While we could allow fetching them from a specified path, I like the idea of the sidecar not reading arbitrary folders of the users by mistake.

Some refactoring changes have been done as well:

• All different signers have been moved to a signer folder
• SignerBLS trait has been transformed into an enum because there's not a common trait for all type of signers
• Config struct has been absorbed into Opts by squeezing Clap functionalities

Relies on chainbound/ethereum-package#17.

[merklefruit]

The config refactor is very nice! Left some comments but overall great.

Wrt the signer, this is what I understand from the current flow with the Keystore:

• sidecar is started with keystore CLI flags + validator-indexes flag
• at each slot, we check if the proposer duties contain one of our validator indexes
• if so, we try to find the pubkey from the keystore and sign the constraints with it

It would be cleaner to use the keystore as source of truth for which pubkeys we can use to sign messages in the first place, instead of going through validator_indexes.

In particular here's how I imagined it:

• sidecar is started with keystore CLI flags
• all pubkeys are loaded in memory when creating the keystore
• at each slot, we check if the proposer duties contain on of our pubkeys
• if so, simply sign it with that key

let me know your thoughts

[thedevbirb]

The config refactor is very nice! Left some comments but overall great.

Wrt the signer, this is what I understand from the current flow with the Keystore:

• sidecar is started with keystore CLI flags + validator-indexes flag
• at each slot, we check if the proposer duties contain one of our validator indexes
• if so, we try to find the pubkey from the keystore and sign the constraints with it

It would be cleaner to use the keystore as source of truth for which pubkeys we can use to sign messages in the first place, instead of going through validator_indexes.

In particular here's how I imagined it:

• sidecar is started with keystore CLI flags
• all pubkeys are loaded in memory when creating the keystore
• at each slot, we check if the proposer duties contain on of our pubkeys
• if so, simply sign it with that key

let me know your thoughts

Thanks for the great review! Yes the flow you described is indeed correct. You're right that in the context of the keystore signer the process of checking validator indexes is redundant. I have to think whether it's still needed for other type of signers though

[merklefruit]

reminder: we're missing a check here. this pubkey is used to sign constraints but we don't know if it is authorized to do so. this can be added after we load delegation info in #290

[merklefruit]

Great job!