Description
If we turn litrpc into a module (which would require turning looprpc etc. into modules as well), we can avoid a bunch of situations with regard to overrides and dependencies. This would make the external (and internal for Loop) development process with Taproot Assets channels significantly smoother and easier. There would be added maintenance work of needing to tag each rpc for any breaking changes.
We would also need to look into proper usage of go.work files and check them in for the rpc stuff. go.work allows the owner of the module to use the local copy without overriding in their go.mod file. However, we need to investigate what happens if you have a go.work file in one repo (let's say lnd) that just points to ./lnrpc for example. Then when you import lnd from a different repo, what version of the lnrpc sub package is then used?
If we wanted to take a look at an example, we do something like this for swapserverrpc.