feat(indy-vdr): did:sov resolver

[genaris]

Following the strategy of 'small PRs', this one adds to indy-vdr package a DID Resolver for did:sov method. It offers the same features as the one based on indy-sdk.

The one for did:indy will be added in a further PR.

[codecov-commenter]

Codecov Report

Merging #1247 (b970c90) into main (b6ae948) will decrease coverage by 0.30%.
The diff coverage is 77.07%.

@@            Coverage Diff             @@
##             main    #1247      +/-   ##
==========================================
- Coverage   87.64%   87.35%   -0.30%     
==========================================
  Files         739      760      +21     
  Lines       17619    18149     +530     
  Branches     2992     3081      +89     
==========================================
+ Hits        15443    15854     +411     
- Misses       2169     2288     +119     
  Partials        7        7              

Impacted Files	Coverage Δ
packages/indy-vdr/src/error/IndyVdrError.ts	50.00% <50.00%> (ø)
...es/indy-vdr/src/error/IndyVdrNotConfiguredError.ts	50.00% <50.00%> (ø)
packages/indy-vdr/src/error/IndyVdrNotFound.ts	50.00% <50.00%> (ø)
...s/src/formats/LegacyIndyCredentialFormatService.ts	64.73% <64.73%> (ø)
packages/indy-vdr/src/pool/IndyVdrPoolService.ts	74.69% <74.69%> (ø)
packages/indy-vdr/src/index.ts	75.00% <75.00%> (ø)
packages/anoncreds/src/utils/credential.ts	76.81% <76.81%> (ø)
packages/indy-vdr/src/pool/IndyVdrPool.ts	85.96% <85.96%> (ø)
packages/indy-vdr/src/utils/promises.ts	88.88% <88.88%> (ø)
...ackages/indy-vdr/src/dids/IndyVdrSovDidResolver.ts	92.10% <92.10%> (ø)
... and 15 more

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

[TimoGlastra]

Some comments, but overall looks good. Nice!

[TimoGlastra]

Do we want to export all these services / methods? I want to be more careful going forward in what we see as public api. I think seeing the specific things built on top of the pool service (so anoncreds registry, did resolver, did registrar) as public api means we can more easily make non breaking changes.

What do you think?

[genaris]

Yes, maybe it's better to be more selective from the beginning.

For the moment I only picked the IndyDidSovResolver, which is the only class (among the existing ones) I think it will be used externally once an IndyVdrModule or so is created.

[genaris]

Some comments, but overall looks good. Nice!

Thanks! I think I covered all the feedback. Some other changes to be added in a further PR.

I noticed it's becoming a bit harder to make CI pass: I had to increase the timeout for some tests (create DID with endpoints and resolve takes ~30 secs) and also I've seen some OutOfMemory/Garbage Collector problems like:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb6b850 node::Abort() [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 2: 0xa806a6  [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 3: 0xd52140 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 4: 0xd524e7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 5: 0xf2fbe5  [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 6: 0xf420cd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]

Not sure if this could be related to the issue found in Askar. If it continues, maybe we can test with a patched ref-napi version to see how it performs.

[TimoGlastra]

Some comments, but overall looks good. Nice!

Thanks! I think I covered all the feedback. Some other changes to be added in a further PR.

I noticed it's becoming a bit harder to make CI pass: I had to increase the timeout for some tests (create DID with endpoints and resolve takes ~30 secs) and also I've seen some OutOfMemory/Garbage Collector problems like:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb6b850 node::Abort() [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 2: 0xa806a6  [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 3: 0xd52140 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 4: 0xd524e7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 5: 0xf2fbe5  [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]
 6: 0xf420cd v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/opt/hostedtoolcache/node/18.13.0/x64/bin/node]

Not sure if this could be related to the issue found in Askar. If it continues, maybe we can test with a patched ref-napi version to see how it performs.

Hmm but Node 18 should work fine right?

[TimoGlastra]

Is this ready to merge otherwise @genaris?

[genaris]

Is this ready to merge otherwise @genaris?

Yes, and if the issue with CI persists we can investigate it further to see where it is taking so much heap memory (and what's different from local node setup, as I haven't seen this particular issue locally).