Investigate pool bootstrap and rebalancing behavior

[eike-hass]

• Effect on Gas Station operation during scheduled rebalancing
• Analyze possible ways to improve performance of coin splits:
  • transaction batching into PTBs during follow-up coin splitting (when after an initial split into up to 2k coins these are broken down into more coins, each follow-up break down currently in a separate tx)
  • breaking coins into more or less exact target sizes, iterating until a single coin is used up
  • similar, but we could also check if we could improve performance by trying to split the coins more "intelligent", e.g.:
    • assuming that an example expected coin count is 4k
    • currently
      • we'd split them into 2000 coins, splitable again, into 2 coins each
      • that would be 1 initial split, plus 2k tx, so 2001 transactions
    • could we flip this, to
      • initially split them into 2 coins
      • then split these into 2000 coins each
      • and do the same as before in 3 transactions? (initial coin, then the 2 child coins)
    • my assumption is, that this would be difficult for a top-up, but might be possible for the initial split
  • collecting coins before breaking them down
  • maybe a combination of the current behavior and a new approach, depending on if we're in initial splitting phase or breaking down top-ups

[eike-hass]

@philou-078 FYI

[philou-078]

I have the intuition that the simplest solution (algorithmically) and the closest to the desired goal (target-init-balance=N) is the one I mentioned on Discord.
=>
Process the coins one by one and split them as many times as necessary into smaller pieces with balance=N (via split_vec).

This maximizes the number of coins obtained and allows for the maximum number of requests to be sponsored (from an initial total balance).