[Bug] Modify caching strategy to better utilize cache space and distribution of resources.

[csuwildcat]

Describe the bug
The current caching strategy effectively renders caching unavailable to the vast majority of DIDs, as it doesn't seem to account for frecency (frequency/recency) of access, activity, or other metrics that substantiate why a DID should be cached over another.

To Reproduce:

1. Try to build an app and not get hit with 10s+ resolutions virtually every time
2. Fail at doing Step 1

Expected behavior:
Step 1 should be the common case.

Supporting Material
I built an app and this the behavior.

Environment (please complete the following information):

• Literally everywhere you can send an HTTP request

Additional context
Not really, just want some caching.

[decentralgabe]

The primary problem is a given server does not know, and has no way of knowing, whether a record has been updated without querying the DHT.

Caching ignores this possibility and increases the chance of failure cases when an update has been published to a different DHT node.

To mitigate this, we have some options:

1. Support introspecting NS records to determine if the gateway is authoritative #199.
   This is the first obvious one. If a DID Document marks a certain node as 'authoritative' we have less of a reason to query the DHT. There's still a possibility the DID updates its authoritative gateway without letting a prior authoritative gateway known, but we can consider that an edge case. We could handle this with an async fetch.

2. We can do an async fetch anyway.
   With this I mean that we favor returning a cached version for the common case. We can make the timeout 2 hours. Asynchronously we can start a background process to query the DHT and update the records, so that on subsequent requests you'll receive an updated DID Document if it's available. This is nice because it's non-blocking. A tradeoff is the risk I mention above (updates external to the node).

3. Async fetch + a consistent read flag
   Same as the prior suggestion, however we enable a new query parameter which is default set to false. Setting a consistentRead flag to true would always query the DHT and take longer. This leaves the behavior up to the client. There is prior art in distributed DBs like Dynamo.

Let me know what you think.

[csuwildcat]

Third option sounds best, with a pref for cache slots given to the DIDs that have the highest frecency of hits.

[decentralgabe]

Frequency of hits does not change the fact that the DID can be updated on another node.

I think supporting 3, then 2, then 1 will give you the behavior you're looking for.