testing: update pingpong transaction sending logic

[tsachiherman]

Summary

This PR addresses several different behaviors of pingpong that doesn't align (anymore) with it's usage:

1. during asset testing, avoid creating assets for the source account - this would generate failures on subsequent iterations.
2. for asset testing, ensure we have sufficient asset supply for the entire rebalancing period.
3. refactor the waiting for next round using a single waitForNextRoundOrSleep method.
4. generate an error when the number of created assets per account surpass the expected value.
5. when distributing assets, avoid using the pps.constructTxn method, as it's randomly select source/destination. instead, assemble the transaction explicitly.
6. sendAsGroup was much simplified by passing the explicit account. The non-possible error cases were removed.
7. in prepareApps, applications are compiled only once.
8. thesenders slice in prepareApps should have been reset. It wouldn't work correctly without it.
9. The pingpong logic of sendFromTo was changed -
   instead of sending traffic, rebalancing and sending traffic again, we calculate the pessimistic remaining balance on each of the accounts. A background go-routine would update all these account. Once the balance on 20% of the accounts drops below the desired level, we attempt to rebalance them. In addition, in 50% of the cases, the pingpong would pick an account that has a low balance as the recipient of the transaction.
   This model allow much longer runs without rebalancing actions takes place, resulting in a more precise and consistent transaction generation.
10. precise rate control. The rate control was improved to ensure we generate transactions at a constant rate, with a 20ms wiggling temporal buffer.
11. a constructPayment was created to replace the libgoal ConstructPayment. The difference is in the source of the getSuggestedParams`, which are refreshed by the monitoring go-routine. This reduces unneeded communication between pingpong and the node.
12. fix some of the allocated funding balances for applications - making sure that we account for the setup costs, so that we won't run out of funds between rebalancing.

Test Plan

Tested running against S1 network