Refactor for Provider Independence

[PJUllrich]

Description of the Feature or Idea

As of now, Joule integrates LND exclusively and the code base is tailored to use macaroons. I assume that in the future, Joule is meant to be usable also with other lightning implementations like c-lightning and eclair and other wallets like e.g. casa, bluewallet, or zap. In order to be able to integrate these frameworks, the code base needs to be provider independent, meaning that the code needs to be agnostic about which wallet or implementation is used. This issue is meant to organize what needs to be done in order for the code base to become provider independent. A solution for this must be discussed of course before being implemented. In the following, I wrote down an initial solution that I came up with so far.

TODOs (extend/edit as needed)

Node Interaction

• Replace adminMacaroon and readonlyMacaroon in NodeState with an abstract class named e.g. LightningService or ServiceState or something similar.
• Discuss which functionality the abstract class needs to implement (e.g. checkNode, checkAuth)
• Create child-classes of that abstract class for every lightning implementation and wallet
• Implement the desired functionality in the child classes

Node Information

• Create a class of GetInfoResponse that holds node information agnostically to which implementation or wallet is used.
• Research which information about the Node is returned by each implementation and wallet
• Create functionality in each child class of e.g. LightingService that creates the agnostic GetInfoResponse and populates it with the desired information returned from the lightning node.

Misc

• Test everything using different implementations and wallets.

Related to

#60 #14 #8

[wbobeirne]

Hey, thanks for the writeup! I actually already began on this for the Casa integration in #171, and have a very similar approach. Here's what I've done so far:

• Remove most top-level keys on the node reducer, and house them all under an auth object. Each node implementation will have its own auth object shape (LND will remain macaroon based, Casa would be password, etc.)
• Remove lib from redux, and construct a LightningHttpProvider each time in the selector. The provider constructed depends on what the auth shape is. These will all stem from a common class. This implementation will look most like LND's API, and other lightning providers will have their responses shaped to match LND as closely as possible.

The current issues I have are as follows:

• Not all node providers offer read-only information in a secure way. For instance, to hit any endpoints on a casa node, you have to have the password. This will make the partial auth style that LND uses impossible, where we store the readOnly macaroon unencrypted.
• I haven't yet implemented a way to migrate encrypted stored data, so it'll be difficult to migrate the encrypted adminMacaroon to this new auth object style.
• A lot of places that didn't expect calls to throw will need to better handle them. Not all node implementations will support all methods.

I'm going to go ahead and assign this issue to myself since I'm already working on it. Let me know if you have any other things to add to it. Hopefully I should have a PR up for review in a bit, but this is touching a lot of the code base, so I don't think this will happen immediately.