The kvdb-to-SQL data migration polls lnd's ListMacaroonIDs RPC, which
only becomes available once lnd reaches its "RPC active" state. On
nodes with a large channel/graph state, lnd can take well over a
minute to get there after the wallet is unlocked, which exceeded the
previous fixed 60-second (120 x 500ms) poll budget and caused the
migration - and therefore litd startup - to fail permanently,
requiring a manual restart.
Replace the fixed attempt cap with a wait bounded by the new
--lndreadytimeout config option, defaulting to a generous 10 minutes,
while still aborting early if the daemon is shutting down. The wait
happens inside the migration's SQL write transaction, so it is kept
bounded rather than unbounded as a safety backstop.
The kvdb accounts db is specifically set to be created in the same
folder as the macaroon path, while the sessions and rules db are created
in the network folder.
That means that users which have set a custom macaroon path, can have
an accounts db in a separate folder than the sessions and rules db.
In order to ensure that the migration from kvdb to SQL uses the correct
db folders, we need to make sure that the migration code uses the same
logic as the creation of the db logic.
Remove the KVDB-to-SQL migration from the dev SQL migration set now
that this migration is now part of the production migration set.
As the migrations_dev folder no longer contains any migrations, we also
update the db logic and the gen_sqlc_docker.sh script to not error when
the folder(s) are empty.
Move the programmatic KVDB-to-SQL migration out of the dev-only
migration stream and into the production SQL migration set.
This also requires that we add a new migration file for the prod
migration, which will trigger the kvdb to sql programmatic migration to
run in production.
With the latest version of the `sqldb/v2` & `migrate` packages, Post
Migration Callbacks were renamed to Programmatic Migrations.
Our previous codebase still had some mentions of Post Migration
Callbacks, and therefore we rename those to use the word Programmatic
Migrations instead.