Refactor/remove lock balance logic in billing flow

[sameh-farouk]

Choosing between locking and distributing less frequently, or not locking and distributing more frequently could be debatable as both actions require modifications to the account balances storage, which involves computational resources.

Locking Tokens: Each lock is recorded in the state, and removing or updating a lock involves additional state changes.

Transferring Tokens: Each transfer results in changes to the state (balance updates) for both the sender and the receiver. Also, distributing tokens in our logic involves multiple transfers to (foundation, sales, staking pool, and service provider) accounts.

The advantages of the current flow:

• Locks due amounts every hour, leading to fewer state changes during the day.

• Transfers the total amount once daily, spreading the computational load.

The disadvantages:

• Current locking logic is flawed
• Locking logic adds complexity to the billing code

I believe that the current approach, if works correctly (which is not the case), is generally more efficient in terms of network usage. However, I propose simplifying the logic by transferring overdue amounts directly every cycle. This is because the added complexity of locking brings many flaws that cannot be justified by the potential savings in network usage.

We can still benefit from both worlds by changing the billing cycle to occur every 24 hours instead of hourly, aligning it with the cultivation distribution schedule. This approach consolidates multiple transfers into fewer transactions, reducing the computational load on the network to even lower levels than what we have currently.

Additional context

• https://github.com/threefoldtech/tfchain/issues/969
• https://github.com/threefoldtech/home/issues/1560