keep public keys fresh

[tomholub]

after #553 and #337

Current logic during compose / adding recipients is:

1. I enter recipient email
2. local database gets checked for public keys. If recipient public key is there, use it for encryption. Else if no public key locally, follow to next step
3. remote public key gets fetched. If no public key is found, recipient turns gray. If public key is found, it gets stored in local public keys, and later used for encryption.

This mechanism is missing a way to keep public keys updated - once it's fetched, we never re-check remote servers for newer versions of the same key.

If we just fetched a public key from local database when recipient was entered (as opposed to fetching it from remote), then we should pull the recipients public keys again from pubkey servers, and do the following:

For each key found on remote server:

• see if we have this key locally associated with the recipient (compare by primary fingerprint). If we don't, import that key for that recipient
• if we do already have it, compare the keys by dateLastModified
  • If the remove key has newer date, replace the local key with the remote one
  • else leave local one as is