lnd+config: add config options for inbound fee discount

[Roasbeef]

Originally requested in this comment.

Right now users can only configure this value with the RPC interface. We should also enable the normal config route as well. Once added, we should update the sample-lnd.conf file:

lnd/sample-lnd.conf

Lines 626 to 633 in 5599b3c

	; The base fee in millisatoshi we will charge for forwarding payments on our
	; channels.
	; bitcoin.basefee=1000
	; The fee rate used when forwarding payments on our channels. The total fee
	; charged is basefee + (amount * feerate / 1000000), where amount is the
	; forwarded amount.
	; bitcoin.feerate=1

[joostjager]

For the outbound fee, I think it makes sense to set a non-zero default. But for the inbound fee, I'd say that zero (no discount) is a logical default.

Any ideas on what the use case could be for a discount by default?

[Roasbeef]

But for the inbound fee, I'd say that zero (no discount) is a logical default.

Yeah agreed re zero as a default.

The gap here is that users right now must use the RPC/CLI to set the value each time vs being able to set a global value using the config here like all the other fee/routing knobs.

[joostjager]

I think a global value that when modified would also apply to all existing channels that use default fees could perhaps be useful, but as far as I know it isn't implemented like that.

Currently the config value is almost alike a hidden parameter to the api call. I think it is debatable whether that is good api design. In the past, there has been confusion with default values on the api level. The most prominent example of that may have been the default fee limit for payments (100% of payment amount). My impression was that forcing api users to set the value has been an improvement.

For consistency I understand that you might want the inbound fee default in the config file, but it does feel like a step in the wrong direction. Removing the outbound fee default and making it an explicit parameter in the api call to me feels like the better direction.

The one place where in and out defaults are needed, I think, is when accepting a channel from a peer. But those defaults could be explicitly limited to that scope.