Revocation handling #3579

[rrrooommmaaa]

This PR handles revocations.

Introduces a separate store to keep fingerprints of revoked keys (as well as some arbitrary additional info).
As OpenPGP and X.509 can potentially have same cryptographic material,
revocation of abcdef also "revokes" abcdef-X509, as well as revocation abcdef-X509 also "revokes" abcdef.
Given that, it's not to safe to load OpenPGP key if there is revocation for its X.509 sibling, even setting revoked flag manually,
because it will be lost during armor/parse. So the storage simply doesn't return such keys as if they are missing in the storage.

close #3579

---

Tests (delete all except exactly one):

• Tests added or updated

---

To be filled by reviewers

I have reviewed that this PR... (tick whichever items you personally focused on during this review):

• addresses the issue it closes (if any)
• code is readable and understandable
• is accompanied with tests, or tests are not needed
• is free of vulnerabilities
• is documented clearly and usefully, or doesn't need documentation

[tomholub]

Looks good :)

[rrrooommmaaa]

Migration may be a bit slow (it loads and parses all the OpenPGP keys in a single batch), but it will only happen if the user migrated to new 'emails' and 'pubkeys' storagewith older version of the extension

[tomholub]

Thanks!

[tomholub]

We have added a requirement for authentication on the backend where there wasn't any. Some mock tests were forwarding requests to real backend which no longer works. I'm updating those tests.