Move Encryptor outside of KeyringController

[danfinlay]

Once #4034 is completed, the next function that could be moved outside of the KeyringController is the encryption functions.

Currently the KeyringController stores accounts and their schema, but these aren't actually the only portions of MetaMask state that might need to be encrypted.

Instead, we should move our encryption related functions into their own module at the MetaMaskController level, so that it can combine encryption-needing state as needed.

Two functions involving the password currently pass through the KeyringController:

• [ ] setLocked
• [ ] submitPassword

Also, a couple methods that assume keyringController manages the password encryption exist:

• [ ] createNewVaultAndKeychain
• [ ] createNewVaultAndRestore

Since we are using obs-store for most of our state objects now, it would probably make sense to take advantage of this architecture for the new encryption strategy.

One implementation idea: SecureComposableObservableStore

We could maybe achieve this goal with a subclass of ComposableObservableStore, as the metamaskController.store instead.

The SecureComposableObservableStore class

• Has a method named subscribeToEncrypted, which emits an encrypted blob instead of the clear text contents.
  • Has a method named submitPassword, and does not emit any events until it has been unlocked.
  • Has a setLocked method that deallocates any secret material and stops emitting updates.
  • Emits events for locked and unlocked.
  • MetaMaskController uses locked and unlocked events to setup the controllers managed by this store.
  • MetaMaskController must also call updateStructure(opts) on its .memStore on both of these events, to add/remove the added/removed controllers from the memStore.

[danfinlay]

No. Just recording likely long term architecture changes. The vault may not need to be in charge of encryption. Just ignore if it's distracting.