min/max payment size in fee params in lsps2

[JssDWt]

trafficstars

This change splits the logic for fee params generation between lsps2 and the grpc protocol, because it adds two fields to the opening fee params. These fields would otherwise not be able to be added without breaking existing clients, or having to trust clients to pass the right parameters. Making these parameters available only in lsps2 gives a clear upgrade path.

The fee params settings for lsps2 are now stored in their own table, specifically for lsps2.

Closes https://github.com/breez/lspd/issues/186

[yaslama]

Why we cannot put them in the same table and even more in the same json, but without sending them in the current grpc implementation?

[JssDWt]

Why we cannot put them in the same table and even more in the same json, but without sending them in the current grpc implementation?

There's 2 arguments for that

• if the configuration in that json isn't updated for a specific api key, we won't know about it until a client conplains it cannot do any payments over lsps2, because max payment size is 0
• this fixes the issue that the token was the one coming from breez server before. With LSPS2, breez server is no longer in the middle. So basically these tokens have to be different from the breez server token anyway.

[yaslama]

Why we cannot put them in the same table and even more in the same json, but without sending them in the current grpc implementation?

There's 2 arguments for that

* if the configuration in that json isn't updated for a specific api key, we won't know about it until a client conplains it cannot do any payments over lsps2, because max payment size is 0

* this fixes the issue that the token was the one coming from breez server before. With LSPS2, breez server is no longer in the middle. So basically these tokens have to be different from the breez server token anyway.

Because the tokens are different, the jsons returned to LSPS2 clients are from different records than the json returned for grpc/breez server tokens, so there is no difference between putting them in the same table or another table. So why create a new table?

[JssDWt]

@yaslama I changed it back to use the same table. I did add a migration to add explicit columns for all opening fee params settings fields. That way it's clear which fields have to be set, and it's harder to have an invalid configuration in the database. The min/max payment size fields are prefilled with defaults of 1000 and 4_000_000_000 repectively.

[yaslama]

@yaslama I changed it back to use the same table. I did add a migration to add explicit columns for all opening fee params settings fields. That way it's clear which fields have to be set, and it's harder to have an invalid configuration in the database. The min/max payment size fields are prefilled with defaults of 1000 and 4_000_000_000 respectively.

Adding fields like that complicates services like dynamic fees which currently receive one json as parameter ans knows how to handle it. We can add constraints to the json field like described in https://docs.yugabyte.com/preview/api/ysql/datatypes/type_json/create-indexes-check-constraints/ or even use json schemas using https://github.com/gavinwahl/postgres-json-schema