(refactor) Transition from revocation registry deltas to revocation status lists

[gmulhearn]

since the move to anoncreds-rs, some of the codebase uses the newer anoncreds status-list types, and other parts still use the old deltas.

As of #1308 , all holder/prover functionality is using status list types for revocation (i.e. for creating revocation states in the proof), however verifier & issuer logic is still using revocation deltas.

This should be refactored such that only status lists are used/exposed (in indy-ledgers, deltas are still used on-ledger, but we shouldn't expose that). This would involve removing the get_rev_reg_delta ledger trait methods, and refactoring the anoncreds trait methods to use status lists.

As part of the refactor, test_agency_batch_revocation should be re-enabled, which is a flakey test likely due to awkward status-list <-> delta transformations.

[JamesKEbert]

I was not actually aware of the newer anoncreds status-list types--was that added as part of the AnonCreds 1.0 spec definition effort or as part of the 2.0 effort? Or somewhere else? I'd be interested in reading/learning more, so any pointers would be appreciated!

[gmulhearn]

@JamesKEbert its in the 1.0 spec https://hyperledger.github.io/anoncreds-spec/#issuer-create-and-publish-revocation-registry-objects . I dont have a better pointer other than the spec 😅.

it's baked into anoncreds-rs, which ditched rev reg deltas etc. so internally our Anoncreds trait impl has been having to convert from deltas to status list before passing it to Anoncreds-rs - since our Anoncreds traits methods still use "deltas" as inputs and outputs.

I'd prefer if it was the job of our AnoncredsLedger (read/write) to do this conversion so that deltas don't make it deeper into our codebase. I believe this is the approach credo has done

[swcurran]

For a bit of background — this change, plus the seqno of the Schema embedded in the CredDefId — were the only two changes needed to “de-Indy” the AnonCreds specification.

Indy’s use of deltas in RevRegEntries requires an “active” Verifiable Data Registry (VDR) component that can calculate the delta based on the input parameters of the request. That’s very difficult for general purpose VDRs like Cheqd or a did:web server. Much better to allow the issuer to be able to publish the full state of the registry on each update, and the client be required to retrieve a “point in time” state of the RevReg (vs. deltas over an arbitrary period). While the size of the state might be a problem for a massive RevRegs, since AnonCreds is limited to RevRegs of max 2k or 3k credentials, a bit array with full state is quite small.

[JamesKEbert]

Thank you for the context--it's a really nice to see change, as I know I've experienced some messy headaches related to the deltas in the past, so something simpler is nice.