Basic performance analysis

[pm47]

Added a very simple performance test and applied a few "optimizations" to try and pinpoint performance bottlenecks.

Here are the results:

incremental change	result
baseline	1000 payments in 72078ms 13htlc/s (senders=8)
store asynchronously	1000 payments in 72078ms 13htlc/s (senders=8)
update sqlite to 3.34.0	1000 payments in 72078ms 13htlc/s (senders=8)
bypass htlc_infos db writes	1000 payments in 78584ms 12htlc/s (senders=8)
bypass payments db calls	1000 payments in 43378ms 23htlc/s (senders=8)
store only the channels commitment	1000 payments in 41594ms 24htlc/s (senders=8)
serialize channel data but do not store it	1000 payments in 18072ms 55htlc/s (senders=8)
bypass channel db writes	1000 payments in 20479ms 48htlc/s (senders=8)
bypass pending relay db calls	1000 payments in 15181ms 65htlc/s (senders=8)
use multiple channels in parallel	1000 payments in 14812ms 67htlc/s (senders=8)

First thing to do imo is rearchitecture the payments handler, probably with payment_hash-indexed child actors, like we do for relayers. This will make us gain 2x, maybe more if it allows us to take full advantage of multiple channels (which we don't currently, see last test).

Further improvements won't be as simple, but at least we know where the gains are.

[pm47]

Added more intermediate steps which show that splitting the local_channels in columns and only updating the commitments part do not change the results.

[pm47]

Follow up in #1871.