refactor crypto SDK

List of refactorizations tasks to do in the crypto SDK:

• class OwnerCryptoContext is too big
• we still get weird errors when some mandatory values are undefined, add assertAllDefined checks in src/crypto.
• refactorize testing (and possibly rethink our testing strategy): for instance in tests for password change, we test behavior in both cases where secrets are already available and where they must be downloaded from backup. This is nice but we may not have to have that much intersection between the two tests. Maybe when secrets are not available just test that secrets are loaded from backup. If they are loaded correctly, then there is no reason the rest of the procedure goes differently than when secrets were already available.
• In classes/index.js, method encryptSecrets should call loadSecretBackup if secrets are not loaded.
• Instead of having two methods prepareBackupKeyUpdate and commitBackupKeyUpdate, we could have just one which is given a callback function to call to update the encrypted secret backup at the server.
• createNewOwnerSecrets should not be given a password but a backup key. There should probably be a higherl-level method initializeCryptoForNewAccount which takes a password as input, derives a backup key from it, and then calls createNewOwnerSecrets.
• in src/HttpApi.js, avoid having to provide ownerId to every call that needs it; code should be able to get this value from the SDK state.
• factorize synchronization of crypto values with backend: for now each method modifying a crypto value (secret or public) is responsible for calling synchronization methods (typically updateSecretBackupOnServer). It would be better if values that need synchronization are modified through “setter“ methods which automatically trigger synchronization. We might have to think about a way to defer synchronization to the end of a batch of modifications. → now in separate issue #76

During refactorization, don' forget to also search for @FIXME (and TODO and XXX) in the code.