[BIP44-239] Prepare to extend prefiltering to EOS wallets for ApplyBlock

[uroboros]

https://github.com/input-output-hk/cardano-wallet/issues/239

#

Overview

• [x] In the BListener, I have extended prefiltering inprefilterBlocks to also prefilter for EO wallets during ApplyBlock
• [x] I have refactored prefilterBlock to return a single PrefilterResult, including a merged result in the case of prefiltering multiple wallet types together (i.e. there is at least one Eo and Fo wallet)
• [x] I have made the prefilter context for HdRnd (which was a list of [(rootId,esk)]) more consistent with Eo prefilter, a Map. Now both are maps.
• [x] I've changed getWalletCredentials to accept a snapshot instead of PassiveWallet (since the snapshot is already available at the call sites and this prevents a double getSnapshot)
• [x] I have moved addrPoolGapByRootId from the wallet layer to the Kernel, since I needed it to write getEosWallets. I also extended addrPoolGapByRootId to include accounts data along with the gap
• [x] I have written getEosWallets, that reconstructs Eo wallets and AddressPools from the AcidState db

Comments

This PR adds prefiltering for Eo wallets during ApplyBlock. This means that we can now create new Eo wallets and track them during ApplyBlock.

NOTE: at this stage we cannot yet create new txs for Eo wallets. This will be in a subsequent commit.

QA

We should test that we can create an Eo wallet, and if there are funds transferred to that wallet (using cardano=cli, say) we should see the funds appear in Daedelus.

We should also test Eo tracking in the presence of an HdRnd wallet! (In this case we have to merge prefilter results for the different wallet types, hence it needs special testing.

[KtorZ]

I believe the invariant error was right, and was there to enforce that after prefiltering a singleton block, we get back a singleton result. Note that using a NonEmpty list doesn't quite solve the issue because we are now swallowing the failing pattern match because of:

     nonEmpty <$> prefilterBlocks_ bs foreigns hdRnds 

If, given a non empty list of blocks, prefilterBlocks was to return an empty list (or, as the original invariant indicated, a different number of blocks), then this is now appears as if there were no credentials at all and we would discard this result, without even knowing that something has happened.

I think the real question here is why do we use a version of prefilterBlocks that relies on a list of blocks, where we do know that we are only passing around a single block.

https://github.com/input-output-hk/cardano-wallet/blob/develop/src/Cardano/Wallet/Kernel/BListener.hs#L210

I agree there's no need for this invariant, the fix however isn't going in the right direction. Rather, make prefilterBlock singular and have it take a single block and then later, in

https://github.com/input-output-hk/cardano-wallet/blob/develop/src/Cardano/Wallet/Kernel/BListener.hs#L312

fallback to a forM ormapM of that function -- that's what the current implementation does anyway.

Moreover, this new function of yours prefilterBlocks_ does a fair job at focusing only on the prefiltering part, leaving to the caller the freedom of getting the corresponding credentials (and not doing this in prefilterBlocks itself). It's nice to keep function doing one-and-one thing only.

PS: stylish-haskell isn't happy :/