search pubic keys of recipients on WKD

[tomholub]

part of #1298

trust it more than results on Attester (search first on WKD, then on Attester if WKD doesn't return public key)

1. port Wkd class from browser extension done
2. add tests for it independently of the rest of the codebase, merge the class unused done
3. another PR to start using this class during public key lookups - this issue

The WKD class must be unaffected by disallow_attester_search_for_domains

[DenBond7]

@tomholub Could you show me the logic that you use for the web extension? Where you use the WKD client to fetch pub keys.

[tomholub]

Every single time when public key is pulled from external sources, it would use a general PubLookup class, which has lookupEmail(email: string) method on it.

It's implemented here: https://github.com/FlowCrypt/flowcrypt-browser/blob/master/extension/js/common/api/pub-lookup.ts

When the method is called:

1. it will try pulling from WKD. If WKD returns any result, then the PubLookup method itself will return that result. If not, it will proceed to step 2
2. try pulling from Attester. If attester returns any result, then the PubLookup method itself will return that result. Else, proceed to step 3
3. return empty result

In the code I linked above, there is also a third pubkey source internalSks which we will not be implementing on Android.

[tomholub]

Inside the Attester class, disallow_attester_search_for_domains would be used so that it returns empty in case searching is disabled on that domain (or completely), meaning this setting does not affect searching on WKD.

[tomholub]

I recommend to open above code in vscode so that you can explore it (with ctrl+click) and get a better understanding of where it is used (right click + see usages) or how it fits together.

[DenBond7]

As I understand it relates to search by email only (for fingerprints we use attester). Right?

I'd like to remind you what logic we use:

1. User types user@example.test
2. We search by email via attester
3. User sends a message. We already have a pub key for user@example.test in the cache
4. User creates a new message again
5. User types user@example.test
6. As we already have a pub key for user@example.test in the cache we make a request by fingerprint(via attester) to fetch the latest pub key to keep keys fresh