derived removal pt 1

[michaelneuder]

WIP of removal of derived field in prysmaticlabs#9883. Builds off of prysmaticlabs#10155.

A few notes on what I am going for here:

1. Delete the derived package from validator/keymanager/. I moved the only unique function from the derived keymanager RecoverAccountsFromMnemonic into the local keymanager package.
2. Moved mnemonic.go, mnemonic_test.go, eip_test.go and tests from the derived keymanager type into keymanager_test.go. (I think there is some room to remove code duplication in the test by moving to a table-driven style--- e.g., TestLocalKeymanager_FetchValidatingPublicKeys and TestLocalKeymanager_FetchValidatingPublicKeys_FromMnemonic aren't that different, so there is a lot of duplicated code. This is out of scope for this PR, just a note for future).
3. I added a boolean field to both the wallet and the local keymanager structs to indicate if it has the mnemonic feature enabled. The bool is accessed by EnableMnenomic(). I am still ironing out if this needs to be a field of both, or maybe just one of them.

This is where it gets a bit messier. The bulk of the derived specific logic lives in the validator/accounts/ dir. The general approach I am taking is to try to merge whatever derived specific logic there is into the local (imported) version of the code and guarding it behind a boolean check against EnableMnemonic().

For example in validator/accounts/accounts_list.go, we have the local (https://github.com/prysmaticlabs/prysm/blob/28e0dc5d09dc709730ae62922f7ee1a2a2c80cff/validator/accounts/accounts_list.go#L55) and derived (https://github.com/prysmaticlabs/prysm/blob/28e0dc5d09dc709730ae62922f7ee1a2a2c80cff/validator/accounts/accounts_list.go#L63) cases for printing the accounts. The goal is to merge these in a cohesive way so that we can remove the derived case all together. What I did was compare the two list functions (listLocalKeymanagerAccounts: https://github.com/prysmaticlabs/prysm/blob/28e0dc5d09dc709730ae62922f7ee1a2a2c80cff/validator/accounts/accounts_list.go#L94) and (listDerivedKeymanagerAccounts: https://github.com/prysmaticlabs/prysm/blob/28e0dc5d09dc709730ae62922f7ee1a2a2c80cff/validator/accounts/accounts_list.go#L152). These functions do mostly the same things, but there are a few specific derived aspects, which I added to the listLocalKeymanagerAccounts function behind a conditional:

if keymanager.EnableMnemonic() {
  validatingKeyPath := fmt.Sprintf(local.ValidatingKeyDerivationPathTemplate, i)
  fmt.Printf("%s %s\n", au.BrightCyan("[derivation path]").Bold(), validatingKeyPath)
}

I can go through the other files in validator/accounts/ and give them similar treatment, but wanted to sanity check this approach before overcommitting!

[james-prysm]

If I'm reading this correctly I think it makes sense.
you are adding a new persistent flag in the wallet to see if mnemonic is enabled, merging derived into imported, and then using the flag to determine if it should receive other information. at a high level this makes sense to me , i do want to see the parsing aspects for web and peopel with existing wallets that have the derived keymanager type to not be affected.

[james-prysm]

🤔 this line didn't make sense to me isn't EnableMnemonic a boolean? why is it checking against keymanagerKind here

[james-prysm]

one thing to consider is wallet migration, those who have the derived type should be parsed and swapped to local somehow with the flag if we want to go with it this way 🤔

[james-prysm]

please look at validator/keymanager/types.go and how parsing works. one worry that I have is the possibility of having a direct/derived directory locally for an existing client. we need a way to safely merge or handle this for existing users. otherwise it will only use the direct file( representing imported) instead of realizing there is a derived filed at the wallet dir.