Wkd selects usable key from all received

[rrrooommmaaa]

This PR selects a usable key among all received from Wkd

close #3017

[rrrooommmaaa]

@tomholub Looks like human@flowcrypt.com fails due to a problem unrelated to this PR.
https://openpgpkey.flowcrypt.com/.well-known/openpgpkey/flowcrypt.com/policy is not reachable.
As for revoked keys -- our goal might be not only to skip them from Wkd's response, but to update ContactStore so these keys won't be usable. How do you think about it?

[tomholub]

As for revoked keys -- our goal might be not only to skip them from Wkd's response, but to update ContactStore so these keys won't be usable. How do you think about it?

Definitely - but maybe not in this PR. There is another issue #3018 to look into that as a followup.

That is also related to issue #3332

I think the overall sequence could be:

• this PR
• issue ability to store more than one public key per recipient #3332 - multiple pubkeys per recipient - in this issue we would also add logic to select the right key to use if one is revoket, one is expired, one is valid etc
• issue process / update revoked and expired keys from WKD response #3018 - also update revocations

Right now, since there is only one public key per recipient email, we'd have to create some logic that would be quite different (I think) from the final situation. Right now, let's say the recipient rotates the key. Old one is revoked, new one is available. We would have to throw out the old (revoked) one and replace it with the new one. As opposed to, after we support several pubkeys per recipient, we can independently update the revoked ones and also all of the valid ones that WKD returns - save them all. Then only once we try to email that recipient (or verify their emails) will we choose the right public key from all of the ones that are available.

[tomholub]

@tomholub Looks like human@flowcrypt.com fails due to a problem unrelated to this PR. https://openpgpkey.flowcrypt.com/.well-known/openpgpkey/flowcrypt.com/policy is not reachable.

Sorry, fixed

[rrrooommmaaa]

I think the overall sequence could be:

• this PR
• issue ability to store more than one public key per recipient #3332 - multiple pubkeys per recipient - in this issue we would also add logic to select the right key to use if one is revoket, one is expired, one is valid etc
• issue process / update revoked and expired keys from WKD response #3018 - also update revocations

Ok, so this PR is ready to merge, as I understood.

[tomholub]

Looks good!

[tomholub]

I just noticed - we are returning armored keys here on the WKD endpoints but that does not reflect how WKD returns keys (which should be unarmored bytes, concatenated). I'll make another issue for this.