make bbolt to SQL migration process friendly to kubernetes and prepare to integrate the SQL migration process inside LND

[ZZiigguurraatt]

Most of lndinit is geared towards helping to initialize and run LND from within a kubernetes environment. For example

• https://github.com/lightninglabs/lndinit/blob/main/README.md#example-use-case-2-kubernetes
• https://github.com/lightninglabs/lndinit/blob/main/example-init-wallet-k8s.sh

tells us how to initialize a wallet in kubernetes.

What is important to note is that these commands, if run a second time result in a no-op if they were already completed before. This allows them to be placed inside a kubernetes deployment startup script and if needed, they will do something on first start, if not, LND will restart normally all the other times. This allows a kubernetes deployment to have no changes required after the first startup to make the following startups work.

We should have a similar experience with migrate-db. We should be able to re-run it and it should be smart enough to move forward with no error if an appropriate SQL DB already exists, whether an old, non-SQL DB existed or not. I've created some more specific issues that I think we should fix to achieve this goal:

• migrate-db: make defaults that match LND and document all defaults when running with -h #75
• migrate-db: automate more steps of bbolt to SQL migration process #76
• migrate-db: gracefully handle the case where no bbolt DB exists #77

.

Also, if we can make these changes, then we will be testing the exact same workflow that we will need once we integrate the migrate-db process directly inside lnd. We plan do do this in later LND releases and I think we should start now by developing that workflow inside the external tool lndinit so that we can get testing out in the field on many nodes before we make this an automatic and integrated process inside of lnd for all nodes.