workspace: leverage `go.work` to manage submodules

[yyforyongyu]

Locally, I use go workspace to please gopls so it's easier to work in submodules. Here's the approach,

Suppose you have a similar dir structure as the following,

.
├── btcsuite
├── lnd
...

Now create the workspace using,

go work init
go work use -r ./lnd
go work use -r ./btcsuite

Which will go through all the modules under ./lnd and ./btcsuite, add them to the go.work file.

IMPORTANT: Remember to remove ./lnd/tools from the go.work file.

You can also run go work sync to update the go.mod for every module.

And your dir would look like,

.
├── btcsuite
├── go.work
├── go.work.sum
├── lnd
...

This approach has a few pros and cons. Pros,

• modules are imported locally in lnd. I can easily edit the submodules and see the effect. For instance, running make unit tags="kvdb_sqlite" pkg=kvdb would now give me an error.
• by running go work sync I can easily update the dependant module versions across all submodules.
• gopls is now happy when working in submodules.

Cons,

• as long as you are in the same or child dir of go.work, you can run go work sync to update go.mod. This can also be a pro, but it will create diffs in btcd and btcwallet in their current branch and this can be annoying.
• our CI builds lnd differently by using older submodules, and we may still forget to tag their versions.

Solutions

There's ongoing debate about whether go.work should be checked into VCS. Because we have multiple projects, taproot-assets, loop, pool, etc, adding a go.work under lnd won't suit our case.

• [ ] update development docs about creating and using go.work
• [ ] add a new make command, check-gomod, that checks all the go.mod files are up-to-date - we could create a temporary go.work file and run go work sync and go mod tidy, fail the check if there are uncommitted changes. This should be built into our github actions.
• [ ] consider creating repo for submodules. This may seem cumbersome at first, but with go.work, working on them locally should be seamless and, it makes us less likely to forget to update submodule versions in lnd.

[Roasbeef]

IMPORTANT: Remember to remove ./lnd/tools from the go.work file.

Why's this step required?

[yyforyongyu]

Why's this step required?

I think it's because the tools package is used to pin versions for the tools we use in builds, not related to the actual code of lnd. The last time I tried to include it, I got quite some errors when running github actions. There may be a catch I'm missing here.