Previous to this modification, the initialization of the sync decrypter pool
could happen concurrently with other database operations. That could cause the
pool to hang because it could be waiting for something that was mistakenly
deleted because of the wrong order of database operations.

This commit implements a standard which we already use in leap.keymanager and
leap.mail which makes some methods wait for the initialization operation
before they are actually called.

Closes: #7386

SoledadCrypto had Soledad as parameter to be able to use
SoledadSecrets. SoledadSecrets had SoledadCrypto as parameter to use
*crypt_sym. This commit removes this circular dependency passing
directly the secret that SoledadCrypto cares about to the constructor
and removing the *crypt_sym methods from SoledadCrypto.

- Resolves: #7338

Because of how the incoming document queue is implemented, it could be the
case that a document was sent to async decryption queue more than once. This
commit creates a list of documents to be decrypted, so we avoid sending the
same document to the queue more than once.

The incoming documents events are meant to be used by a progress bar for
soledad sync, yet to be implemented. When deferred decryption was used, the
events were sent out of order, depending on the order of arrival of the
documents. This commit changes it so that the content of the emited events are
in order, so it is meaningful for the implementation of a progress bar.

Note that even after documents are received from the server, they will still
be decrypted asynchronously, so another signal could be implemented to signal
for the waiting of the decryption of incoming documents.

This is how a secret was stored in the secrets json file:

  * each secret is symmetrically encrypted amd MACed with keys derived from
    the user's passphrase.

  * the encrypted secrets dictionary is then MACed with another key derived
  * from the user's passphrase.

  * each key is derived using scrypt and a unique random salt.

There are disadvantages to this approach:

  * repeating scrypt many times is a waste of time.

  * an attacker could crack whichever has weaker parameters, if they get out
    of sync.

  * if an attacker can modify the secret in a way it is good to decrypt the
    database, then she can also modify the MAC.

The solution for this is:

  * completelly eliminate the MAC from the storage secrets file.

  * attempt to decrypt the database with whatever is got from the decryption
    of the secret. If that is wrong, report an error.

Closes #6980.