Tower payments pay endpoint: WIP

[orbitalturtle]

This PR begins to add payment support to TEOS. I'm realizing I have a lot of thoughts and the project is a bit bigger than I expected. So figured I'd try to see if I can get a little feedback on the approach I'm taking before I get too far along. 🤞🏻

Approach so far:

I've started by creating a new "pay" endpoint. This will be used to grab an invoice to pay when a user needs to register or top up their account (maybe a more accurate name would just be "get_invoice" to then pay after).

The steps for a user to make a payment (for initial registration or for a top up) are:

• Hit "pay" endpoint to grab an invoice.
• Pay the invoice.
• Hit "register" endpoint, where the tower will validate that the user actually paid the invoice and the user will receive the receipt for registration.

On the tower side, once a user hits the pay endpoint for the first time, the tower associates the user's provided uuid with the invoice, and stores it in memory and in the db. IMO the advantages of "one-invoice-per-user" model are that:

• The user won't waste resources if they hit the "pay" endpoint a million times. Instead of needing to generate a new invoice for every call (clutting the tower's lightning node db and making it harder to look through listinvoices to see if a payment is indeed paid), the tower will just return the invoice the user hadn't yet paid earlier.
• A nice side effect I guess is the user won't have to provide any sort of proof of payment to the tower. The tower will just know if the user has paid their associated invoice or not.

Future stuff: This will come in future PRs

The above all takes the endpoint logic into account. After that, we'll need to build some other things:

• Validator - As @sr-gi and I had talked about earlier, the validator is for now behind a trait so that any lightning implementation can eventually be used to generate invoices/verify payments. At some point we'll need to implement one option (perhaps starting with CLN?) to actually allow payments.
• Once the pieces above are in place, we'll add config options, allowing the watchtower to turn on required payments & specify the payment amount they require for how many subscription slots, etc.
• Add the ability to make these payments in watchtower-plugin. (And perhaps some integration tests to make sure everything is working together correctly?)

[aruokhai]

In the description laid out, an implicit assumption is made, which is that a user should have an existing channel with a route of payment to the said watch tower. Such assumptions might not be expected by all users, who may prefer to use normal bitcoin transfers. Such example would be in the case of private channels amongst known participants. I implore the consideration of normal Bitcoin transfers and also the consideration of Silent Payments which help in the case re subscription without explicitly asking for an invoice from the said watchtower.