Support for version migration

[sekulicd]

This contains working code for migrating v091 Vault to v1 Ocean's Wallet. This uses V2 badger/badgerhold to fetch v091 Vault and V3 badger/badgerhold to insert Wallet into Ocean datadir db. This adds migration for trade domain. This adds migration for deposits domain. This adds migration for withdrawals domain. This adds migration for webhooks. This adds migration for tls. This adds migration for macaroons.

Closes #715.

@altafan please review.

[what-the-diff[bot]]

PR Summary

• Migration from v0.9.1 to v1 Added the migration process for updating from version 0.9.1 to version 1.
• Data Migration for Vault and Markets Migrated the data for vault and markets accordingly.
• New Interface for Market Repository Introduced a new interface to improve the interaction with the market repository.
• Logic Moved to Domain Layer Shifted all the logic from the repo manager to the domain layer for better organization and maintainability.
• Badgerhold Code Update Refactored the badgerhold code to utilize the latest version (v4) and updated its API for compatibility.
• Package Additions and Removals Added the 'btcutil' package, removed the indirect tag from 'websocket', and added the 'klauspost compress' package (indirectly).

[tiero]

The existing datadir should be renamed to tdex-daemon-v0 and a new one should take its place along with the oceand one. Ideally, after one runs the migration he should be able to run ocean and tdex-daemon without any other intermediate step (if not required because he specifies different folders with flags).

What about migrating to a new folder? .tdexd or .tdex-daemon-v2

[altafan]

What about migrating to a new folder? .tdexd or .tdex-daemon-v2

I don't really like this solution mainly because the operator would need to customize the datadir of the new version. In addition, in a dockerized environment, one would have to change the volume mounted on the container which doesn't sounds so frictionless to me.

What if we modify the v0.x datadir as the v1 expects, create the ocean folder inside the daemon's datadir and move everything already existing to a dedicated folder like v0.9.1-datadir. This way we don't loose anything, and the daemon is still easy to start without modifying anything but the env vars (whether it is served as standalone binary or docker container).

[sekulicd]

What about migrating to a new folder? .tdexd or .tdex-daemon-v2

I don't really like this solution mainly because the operator would need to customize the datadir of the new version. In addition, in a dockerized environment, one would have to change the volume mounted on the container which doesn't sounds so frictionless to me.

What if we modify the v0.x datadir as the v1 expects, create the ocean folder inside the daemon's datadir and move everything already existing to a dedicated folder like v0.9.1-datadir. This way we don't loose anything, and the daemon is still easy to start without modifying anything but the env vars (whether it is served as standalone binary or docker container).

This question is related to the deployment strategy and we need to decide exactly how we are going to do this so we know where to put outputs. From my POV this is one time operational job and i dont think its important that is completely frictionless. I would maybe force user to provide source datadir, run binary and in same loc two datadirs would be generated(tdexd, ocean), and also maybe we can add docker image that starts all services and binds voluems etc.

[tiero]

ok to rename the folder then! I think Docker is where we have more friction anyway, so its important to make a clear migration guide for the raw edges

[altafan]

My vision is that the dockerized daemon should be migrated by running just one command without any "customization", while for the standalone binary, one would use custom output folders indeed for the new datadirs.