refactor(cache)!: change default cache to in memory

[TimoGlastra]

Changes default cache implementation to an in memory cache. This simplifies the caching, and makes sure it works for all cases (nodejs/react-native, but also mulit-tenancy).

BREAKING CHANGE:
The default cache implementation has been changed from SingleContextStorageLruCache to InMemoryLruCache. In React Native environments it is still recommended to use the SingleContextStorageLruCache cache implementation, but due to it's dependence on the wallet storage, it is not recommend for server side or multi-tenancy deployments. A custom caching interface can be implemented in those cases.

[codecov-commenter]

Codecov Report

Merging #1389 (9ece062) into main (343ce6a) will increase coverage by 3.49%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1389      +/-   ##
==========================================
+ Coverage   81.82%   85.32%   +3.49%     
==========================================
  Files         788      788              
  Lines       19405    19406       +1     
  Branches     3150     3150              
==========================================
+ Hits        15879    16559     +680     
+ Misses       3519     2840     -679     
  Partials        7        7              

Impacted Files	Coverage Δ
packages/core/src/modules/cache/CacheModule.ts	100.00% <100.00%> (ø)

... and 14 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[genaris]

I don't know the details about it but an in memory cache makes me think that, unless a server has 100% of uptime, it will be lost. Would that be something that we should leverage using by default?

I totally agree that it's still better than SingleContextStorageLruCache for multi-tenancy and probably also for server-side single-tenancy agents, but given that AFJ is mostly used in Mobile Agents where, as you said, it's preferable to use the other one, I'm not convinced that in memory should be set to default in 0.4.0.

The main concern about SingleContextStorageLruCache is that it does not work in multi-tenancy, right? In such case couldn't be an error thrown at agent initialization when attempting to use it for multi-tenancy?

As I said previously, I don't know so much about the context so it's very likely that my reasoning is wrong, but that's what I'm thinking based on some things that we recently defaulted to the 'right way' and caused some troubles to current AFJ audience (e.g. setting the did:key flag to true in 0.3.0).

[TimoGlastra]

I don't know the details about it but an in memory cache makes me think that, unless a server has 100% of uptime, it will be lost. Would that be something that we should leverage using by default?

I totally agree that it's still better than SingleContextStorageLruCache for multi-tenancy and probably also for server-side single-tenancy agents, but given that AFJ is mostly used in Mobile Agents where, as you said, it's preferable to use the other one, I'm not convinced that in memory should be set to default in 0.4.0.

The main concern about SingleContextStorageLruCache is that it does not work in multi-tenancy, right? In such case couldn't be an error thrown at agent initialization when attempting to use it for multi-tenancy?

As I said previously, I don't know so much about the context so it's very likely that my reasoning is wrong, but that's what I'm thinking based on some things that we recently defaulted to the 'right way' and caused some troubles to current AFJ audience (e.g. setting the did:key flag to true in 0.3.0).

Yeah good point. Maybe we can automatically set the cache implementation based on environment / setup. I think for server implementations it's fine to store the cache in memory and promote users to provide their own caching implementation (or we could add default implementations for e.g. redis). But for RN we probably don't want to use the in memory cache. 👍