[feature]: add distinct SQL database migration "tracks" in sqldb

[guggero]

Today, the way SQL database migrations work with golang-migrate/migrate is that we only have a single "track" of migrations, meaning a single folder with migration files that need to be numbered in a strictly incremental way.

But because we'll have optional migrations in the future (either toggled through a CLI flag such as the --db.use-native-sql flag or through build tags to toggle not-yet-finished features in unit or integration tests), keeping things in strict order might become tricky.
Especially if there are multiple, distinct sub-projects working on migrating databases over to SQL (the existing invoice DB and the upcoming payments and graph databases), there are bound to be conflicts.
Also having those three (and in the future even more) distinct functionality sub-projects create files will lead to a hard-to-understand sequence of files.

We can start using different tracks if we change the following:

• Specify a distinct MigrationsTable for each track in pgx_migrate.Config{}. The default would be schema_migrations which we would use for existing migrations (e.g. the native invoice migrations). Any new "track" would get a different name, for example: schema_migrations_payments or schema_migrations_graph. See
• Store the files for each track in a different folder and specify that here:

  lnd/sqldb/postgres.go

  Line 182 in 7e54682

  postgresFS, driver, "sqlc/migrations", dbName, target,

As a side task it would make sense to move any of the actual migration lists or feature specific functionality out of the sqldb package so it only contains generic code that can be re-used in our other projects.

[Lymah123]

Hi @guggero and @saubyk , can I work on it?

[saubyk]

Hi @guggero and @saubyk , can I work on it?

Hi @Lymah123 since you don't have a track record of any LND contributions yet, would recommend going through the new contributor's guideline first:
https://github.com/lightningnetwork/lnd/blob/master/docs/review.md

Assuming you are familiar with how Bitcoin & Lightning Network nodes work, first focus on learning how code contributions are made to LND by reviewing existing prs. After you have a track record of a couple of pr reviews, you should think about putting up a pr of your own.

Hope this helps. thanks.

[Lymah123]

Hi @guggero and @saubyk , can I work on it?

Hi @Lymah123 since you don't have a track record of any LND contributions yet, would recommend going through the new contributor's guideline first: https://github.com/lightningnetwork/lnd/blob/master/docs/review.md

Assuming you are familiar with how Bitcoin & Lightning Network nodes work, first focus on learning how code contributions are made to LND by reviewing existing prs. After you have a track record of a couple of pr reviews, you should think about putting up a pr of your own.

Hope this helps. thanks.

Thank you @saubyk, I will start implementing your suggestions.