openingd: Allow users to set the enforced reserve for their counterparty (zeroreserve)

[cdecker]

Based on top of #5275, this PR starts at commit f7d0827154302e6920946509df5756a8c79cb017

Until now we always applied the default reserve of 1% of the funding amount, however there has been considerable demand to being able to adjust these values. In particular zeroreserve, i.e., not enforcing any minimal amount in the channel from the counterparty, has been an often requested feature. This PR implements the zeroreserve proposal, in two variants (see second to last commit):

• The first variant implements the prescribed checks from the spec, ensuring that both the remote and the local fees are above the dust limit, resulting in some dust and at least one forced output for both sides should they have ever reached a sufficiently high balance
• The second variant skips the prescribed checks, allowing true 0 reserve, and users can drain their channels completely. This is a more trusted setup since the party that gets permission from the other side to fully drain their channel can replay an old state without repercussions

The implementation itself is done via a new reserve argument to the single funding RPC commands, and by adding a new reserve return argument to the openchannel hook. The values are absolute satoshi values, not percentages.

Using arguments and hooks allows the caller or a plugin to selectively opt into allowing the counterparty to drain the channel, based on the nodeid, amount or any other information in the openchannel hook (potentially including dynamic lookups). I think this is the best way to allow users to selectively opt-in without them automatically allowing everybody.

Either way a stern warning about the trust involved should be added to the docs.

Open questions

• [x] I guess the big one is do we feel ok allowing sub-dust reserves, should it be a user option, and if it's ok, should we propose a spec amendment removing those checks?
  • Amending the spec may require a featurebit since at the moment we actually enforce the sub-dust check for the reserve our peer imposes on us too, making this a breaking change that could fail the channel funding flow. Then again, we presume some level of coordination and trust before attempting to open a zeroreserve channel, so that breakage might be ok.

[niftynei]

Deferring to next release pending small fixes.

[cdecker]

ACK https://github.com/ElementsProject/lightning/pull/5315/commits/afed054c8750d716341299800c3499a04aa5f8ab