Make use of `lightning::util::anchor_channel_reserves` to improve anchor reserve estimation?

[tnull]

Rather than always requiring the user a flat fee, we could consider to make use of the changes in
lightningdevkit/rust-lightning#3487 to allow for a more detailed estimation.

[tnull]

We explored using lightning::util::anchor_channel_reserves in #674 and found that AnchorChannelReserveContext::default() results in reserve values that are unfeasibly high for most (edge) users.

We played around with the numbers there, and it seems we'll have to set really low AnchorChannelReserveContext parameters to arrive at reasonable (comaparable to our current default) reserve values. So, just as before, it will be very hard to set sane default parameters that make sense for ~all or ~most users. It likely comes down to 'user profiles': if you run a forwarding node that is exposed to a lot of HTLC-related risks, you might want to bump the numbers or use AnchorChannelReserveContext::default() numbers. Most edge nodes however likely want to considerably reduce these numbers.

Hence, most users will continue to have a very hard time to wrap their head around what risk they are taking and what numbers they should pick here, which is exactly what we hoped to improve upon by using the anchor_channel_reserves util over just having them choose some per-channel reserve value.

So, at some point it might make sense to introduce the notion of 'user profiles' as a general concept, but I'm not sure right now is the right time to do that. So I think we should just kick the can down the road a bit further, and revisit this issue some time down the road, maybe in conjunction with Server-specific behavior (cc @benthecarman).