Improvements in AFJ's handling of Indy VDR and Indy Networks

[swcurran]

Issue #1613 investigates the performance of (particularly) AFJ-based Wallets (built on Aries Bifold), notably around the loading of a first/new issued credential. From that, and a meeting held with the lead maintainer on Indy VDR, we have some specific suggestions for updates to AFJ that should improve performance. I'll update this note with a reference to materials created about the issues covered in that meeting.

Note that also in the works are some improvements to Indy VDR in the area of ledger node caching, as noted in Indy VDR Issue 240 that once implemented should be reflected in AFJ and other Indy VDR callers.

Suggestions of changes:

• Before opening ledgers, the JavaScript wrapper settings (defined here) should be called and settings made. Suggestions from Indy VDR Issue 241 should be reviewed (as I write this, the final suggestions are incomplete -- so look there).
• Immediately after opening an Indy Pool, a refresh should be done, and the resulted collected and used in place of the genesis file transactions whenever the ledger is opened again.
  • The reason for this is covered in Indy VDR Issue 240, tl;dr the genesis file contains a point in time list of transactions from the Indy "Pool Ledger" -- txns that add/remove ledger nodes. Using the genesis file mean that transactions to remove nodes from the ledger are missing, resulting in the possibility that non-existent nodes are being called for reads. By always processing all of the Pool ledger transactions, the latest set of nodes is known.
• A periodic call to refresh the ledger pool should be done to catch up any new Pool ledger transactions.

Some of these changes may have been done in the recent updates to improve wallet/AFJ Indy performance - #1605, #1618 #1623.