Optimize ChannelMonitor persistence on block connections.

[G8XSU]

Currently, every block connection triggers the persistence of all
ChannelMonitors with an updated best_block. This approach poses
challenges for large node operators managing thousands of channels.
Furthermore, it leads to a thundering herd problem
(https://en.wikipedia.org/wiki/Thundering_herd_problem), overwhelming
the storage with simultaneous requests.

To address this issue, we now persist ChannelMonitors at a
regular cadence, spreading their persistence across blocks to
mitigate spikes in write operations.

Tasks:

• Don't pause events for chainsync persistence Don't pause events for chainsync persistence #2957 and base it on that.
• Concept/Approach Ack
• Decide a good default for partition_factor
• Maybe we can make partition_factor user-configurable. (Can also do this later, depends on our default value)
• Write more tests for persistence with partition_factor.

Closes #2647

[wpaulino]

Is this something we might want to consider not doing on mobile? Thinking that we won't be able to RBF onchain claims properly if the fee estimator is broken and we're not persisting the most recent feerate we tried within the OnchainTxHandler.

[TheBlueMatt]

I guess we should/could consider always persisting if there's pending claims (eg channel has been closed but has balances to claim)? Alternatively, we could always persist if we only have < 5 channels.