pay: Track payment completion time for successful payments

[cdecker]

Track completion time for succesful payments

BY adding the completed_at field to the payments table, and the
sendpay, listsendpays and waitsendpay output we can derive the
completion time for a payment by taking the lowest completed_at
among all parts that were sent. By definition the earliest successful
part guarantees that the payment as a whole will complete, even if
some parts are delayed or stuck. This is because any successful part
communicates the payment_preimage which is the same across all
parts.

For unsuccessful payments we might want to use the first
completed_at after the last created_at time, i.e., the first part
that did not cause a new part to be sent. This usually means we ran
out of routes or time, and pay didn't start any new attempts. Is
that a good interpretation of the completion time for unsuccessful
payments?

[niftynei]

postgres is unhappy

lightningd-1 2022-07-10T14:09:52.886Z **BROKEN** lightningd: s32 field doesn't match size: expected 1, actual 1?
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: FATAL SIGNAL 6 (version 64534d8-modded)
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: common/daemon.c:38 (send_backtrace) 0x55f9f5c76f70
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: common/daemon.c:46 (crashdump) 0x55f9f5c76fc4
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 ((null)) 0x7f727f63008f
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: ../sysdeps/unix/sysv/linux/raise.c:51 (__GI_raise) 0x7f727f63000b
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: /build/glibc-SzIz7B/glibc-2.31/stdlib/abort.c:79 (__GI_abort) 0x7f727f60f858
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: lightningd/log.c:851 (fatal_vfmt) 0x55f9f5c19c69
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:61 (db_fatal) 0x55f9f5c55930
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: db/db_postgres.c:190 (db_postgres_column_int) 0x55f9f5cdc08d
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: db/bindings.c:54 (db_col_int) 0x55f9f5c963c7
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:3247 (wallet_stmt2payment) 0x55f9f5c5e7a5
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: wallet/wallet.c:3299 (wallet_payment_by_hash) 0x55f9f5c5e8c0
lightningd-1 2022-07-10T14:09:53.053Z **BROKEN** lightningd: backtrace: lightningd/pay.c:341 (payment_succeeded) 

[cdecker]

Got it, the column was wrongly set to be BIGINT whereas it should be INTEGER, that explains the mistmatch.

[cdecker]

ACK e7511a4