Refactor identity state management

[Gudahtt]

Our "identity" related state is spread out amongst many different places:

• The KeyringController (eth-keyring-controller) holds references to the keyrings, and is responsible for the global lock/unlock and certain keyring interactions
• The KeyringController wrapper class (i.e. KeyringController.ts, which is a wrapper around eth-keyring-controller) exposes methods for interacting with the underlying KeyringController, and for performing actions that affect identity-related state throughout many controllers
  • Side-note: In the extension, the closest equivalent to this wrapper class is a collection of kerying-related methods that are directly in metamask-controller.js
• The individual keyrings hold keyring-specific state, and expose certain keyring interactions to both the KeyringController and external callers
• The PreferencesController holds a mapping of accounts to account names, which it calls an "identity"
• The PrefrencesController holds the "current selected address"
• The AccountTrackerController holds a mapping of "identities" to balances

At each of these layers, methods are exposed to directly interact with this data from anywhere else in our codebase, providing few protections against making changes that result in contradictions between these pieces of state.

So my questions are:

• How should we divide these responsibilities? Does the current distribution of responsibilities make sense?
• How can we ensure all of this state remains internally consistent?

[desi]

The accounts team has implemented a new controller for Identity State management which is the AccountsController and are in the process of migrating the clients to use that. That should cover this issue so closing this one.