Check on every fetch of the private key if the expiration is less than
two months before it expire. And extend the expiration if needed.

- Resolves: #8217

We are not planning to regenerate keys (for now), only to extend the
expiration date.

We were considering to reset the sign_used flag to force the new key to
be resend as attachment in forthcoming emails. Although, this is not a
good solution, because we'll lose information about which keys the
client has signed.

Previously, we were sending the key attached as long as the contact
hasn't replied back. But with new key replace scenarios, we need to updated
the contact keyring with the new key.

We can implement autocrypt or similar in the future, but for now, let's
send the key attached on every email.

This was intended to offer the option of only extend the old key and
not change it for a new one. However, we don't plan to use this
behavior anymore.

This changes reflect python-gnupg naming.
With @aarni

Previously, new_expiry_date was calculated by the key creation date + 1
week, but the proper behavior is today + 1 week, accordingly with gpg
behavior.

- private key is not allowed to be fetched remotely
- fetch_remote needs to be specifically set
- if a new key is fetched (ie different KeyID), the validation
  rule applies