askrene: fixup fee and delay computation

[Lagrang3]

Askrene fixup fee and delay computation

Description

Sendpay's API expects a route description where the i-th hop contains an amount corresponding to "The amount expected by the node at the end of this hop" and a delay field corresponding to "The total CLTV expected by the node at the end of this hop".
That means the final amount and the final cltv is what is expected in the last hop and we compute backwards from there
the amounts and delays for the rest of the hops.

Eg. the chain of nodes
N1 ---> N2 ---> N3 ---> N4

where
N1-->N2 are connected by channel c12 with zero proportional fee and 3 base fee, delay 6
N2-->N3 are connected by channel c23 with zero proportional fee and 10 base fee, delay 6
N3-->N4 are connected by channel c34 with zero base fee and 2 ppm proportional fee, delay 6

If we want to send x=1e6 msat with final CLTV=10, sendpay expects
[{channel: c12, node: N2, delay: 22, amount: 1000012msat},
{channel: c23, node: N3, delay: 16, amount: 1000002msat},
{channel: c34, node: N4, delay: 10, amount: 1000000msat}]

[rustyrussell]

No, this is deliberate; the sendpay API is wrong.

[Lagrang3]

Hi @rustyrussell, I know sendpay API is a bit messed up.
But if the amounts and delays were correct in getroutes output, let's say correct in the sense of readiness
and no further processing is necessary before using those numbers to feed into injectpaymentonion, then
how come xpay parses from getroutes hops the amount as amount_in while using amount_out (which is the same
as amount_in but shifted by 1 index) to pass to injectpaymentonion?

lightning/plugins/xpay/xpay.c

Line 1063 in 54555ce

hops[j-1].amount_out = hop->amount_in;

I stumbled upon this while adding getroutes to renepay.
It is a bit awkward to read the paths array and shift one of the fields by one index for apparently no reason.

Is it too late to redefine the meaning of amount_msat in the hops?