refactor!: remove indy from core

[TimoGlastra]

The long awaited change. This pr removes all dependency on the indy-sdk from the core package. The indy-sdk is still availalbe through a custom package.

Tests in core still depend on indy-sdk, mainly because askar storage is slow atm, and we still need to do some more work to create lighter tests that only depend on e.g. an in memory wallet.

It's a REALLY BIG pr, as I've approached this in the dumbest way possible. I started out by removing indy from the agent dependencies, which led to an error, and then I was three days in needing to rewrite 90% of tests because they all dependend on the indy-sdk.

I think this is the last really big PR, after which we're going to need to do a lot of small improvements before we can make the 0.4.0 release.

That said, I was able to remove over 9000 lines of code

I also updated the demo where one side uses askar and the other indy, but it's currently broken due to the seed not deriving the correct did as it was registered on the netwrok as it should actually use fromSecretKey. Once we can create keys from the secretKey in AskarWallet we can create the correct did.

[codecov-commenter]

Codecov Report

Merging #1286 (133fdca) into main (616b908) will increase coverage by 1.27%.
The diff coverage is 89.47%.

@@            Coverage Diff             @@
##             main    #1286      +/-   ##
==========================================
+ Coverage   85.17%   86.45%   +1.27%     
==========================================
  Files         835      773      -62     
  Lines       20770    18298    -2472     
  Branches     3557     3101     -456     
==========================================
- Hits        17691    15819    -1872     
+ Misses       3072     2472     -600     
  Partials        7        7              

Impacted Files	Coverage Δ
packages/anoncreds/src/AnonCredsApi.ts	70.44% <ø> (ø)
...s/src/formats/LegacyIndyCredentialFormatService.ts	75.14% <0.00%> (+9.42%)	⬆️
packages/anoncreds/src/models/exchange.ts	100.00% <ø> (ø)
.../credentials/v1/handlers/V1CredentialAckHandler.ts	100.00% <ø> (ø)
...ls/v1/handlers/V1CredentialProblemReportHandler.ts	71.42% <ø> (ø)
...eds/src/protocols/credentials/v1/handlers/index.ts	100.00% <ø> (ø)
...es/anoncreds/src/protocols/credentials/v1/index.ts	100.00% <ø> (ø)
...eds/src/protocols/credentials/v1/messages/index.ts	100.00% <ø> (ø)
.../anoncreds/src/protocols/proofs/v1/errors/index.ts	100.00% <ø> (ø)
...ols/proofs/v1/handlers/V1PresentationAckHandler.ts	100.00% <ø> (ø)
... and 118 more

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

[genaris]

Even if there were a massive amount of lines and files involved in this PR, it was quite straightforward to review. Maybe it's because of the excitement!

I have not commented a lot because, even if there are some TODOs and remaining improvements, we can tackle them afterwards.

The only functional doubt I have is regarding the V1 credential and proof protocol feature registration but otherwise you have my blessing!

[genaris]

I just would like to settle also in GitHub my feelings about using this term because I know it's clear for everyone involved in this for some time that it came from 'Indy shared components'. But I don't want to commit the same mistake of carrying the legacy forever and confuse newcomers (I'm basing these words on my own experience).

For the time being I think it's nice to reflect it in this demo and be explicit that we support both the Indy SDK and the 'replacement shared components', as this is a major stepping stone for AFJ and we are super excited about it.

But in a near future I would like to simply set a demo based in Askar or the InMemoryWallet, showing the exchange of AnonCreds and JSON-LD credentials and making this modular architecture to seem natural and clearly ledger/credential format agnostic.

[TimoGlastra]

Good point, fully agree!

[TimoGlastra]

I've changed the parameter name to useLegacyIndySdk for now

[genaris]

This is true, as we are always using a LegacyIndyProofFormatService. It will represent that we'll use separate instances for V1 and V2 protocols. If we foresee that most agents will support both protocols, it won't be so different in terms of simplicity.

[TimoGlastra]

My initial approach was that you register credential formats also in the agent and the protocols could hook into it. But I changed it so you have to provide the formats yourself. Do you think we should change it?

What do you think will be the simplest way to give users flexibility?

[genaris]

Oh, I think I misunderstood the comment. I thought that you would like to remove indyProofFormat from constructor parameters and simply do a this.indyProofFormat = new LegacyIndyProofFormatService().

But I think it's fine the way it is, letting to provide the formats we want.

[TimoGlastra]

The only functional doubt I have is regarding the V1 credential and proof protocol feature registration but otherwise you have my blessing!

Can you elaborate on this part?

[TimoGlastra]

Thanks for the quick review! That must be around 1000 lines / hour since the Pr was ready for review!

[genaris]

The only functional doubt I have is regarding the V1 credential and proof protocol feature registration but otherwise you have my blessing!

Can you elaborate on this part?

I don't know if it was me who forgot to push a button, or GitHub that lost my comment... But was about registering V1 credential/proof protocol in the FeatureRegistry in AnonCredsModule. I haven't seen it among the changes so I suppose they are forgotten.