universe: finish multi-verse database

[Roasbeef]

No description provided.

[Roasbeef]

Related to lightninglabs/tap#40.

We already have the universe forest abstraction, just need to make another tree on top of that.

[dstadulis]

Potentially defer to v0.2.1 would be stretch goal for v0.2

base: outpoint || scriptKey -> leaf
multi -> assetID/groupKey -> base # another layer of the tree
outpoint -> assetid -> scriptKey # can pick an arbitrary output on chain and see if anything is in it

https://github.com/lightninglabs/taro-private/blob/main/tarodb/universe_forest.go
ProofCourier Interface

[dstadulis]

relevant bip parts
https://github.com/lightninglabs/taproot-assets/blob/main/docs/bip-tap-universe.mediawiki#user-content-Asset_Multiverses

[ffranr]

This is the tracking issue for the OKR:

"Key Result 3: Extend existing universe RPCs to support multi-verses"

[Roasbeef]

Worth noting that this is basically the start of it: https://github.com/lightninglabs/taproot-assets/blob/main/tapdb/universe_forest.go

You'd then need to refactor the base universe stuff a bit (allow the methods to pass in the interface), then call those from the multi-verse method. The above obtains all the roots, which then needs to be inserted into a tree. That tree then needs to be updated each time things are inserted in any of the main asset roots.

Users ideally can have more filtering flags to track basically everything, or just those for a given asset that they care about.

We'd then want to make a courier implementation, and potentially also a proof archive backed by the new db logic.

[ffranr]

Questions for @Roasbeef:

I think the RPC endpoints should just call into MintingArchive which will then make use of universe.BaseBackend and MintingArchive.cfg.UniverseForest. Does that sound correct?

As a first step, I'm going to extend the universe.BaseForest interface with a RegisterIssuance method. Let me know if that's not right.

In this commit I rename the BaseUniverse in the RPC server to MintingArchive: 680ce67

[ffranr]

New issue for tracking the proof distribution aspect of this work: #344