Implement deferred transactions queueing

[cptn-solo]

Implement deferred transactions queueing

[cptn-solo]

Some notes added to IA (revenue share page):

Allocation workflow

Case of branch stakeholders revenue allocation using deferred transactions:

1. When revenue generated and all cuts from it made, its time to allocate it according to branch stakeholders ledger;
2. As there could be many stakeholders of the branch, allocation is split into several stages as follows:

• branch id and revenue amount is captured into the contract state with id of revenue event assigned (tipstakes table);
• deferred transaction can be used to process revenue events, but this approach would not guarantee allocation. The main purpose of this transaction could be to iterate through branch stakeholders ledger and to assign the event id (effectively a receipt number) to each ledger record upon calculation and addition of revenue share according to recorded stake at the moment of transaction;
• stake ledger records can append revenue from each revenue event id only once - contract would not accept request for revenue share from event with id bigger then currently recorded in the ledger for stakeholder;
• obviousely, iterating through big number of stakeholders (even scoped by branch id) to allocate revenue has some performance risks. It would be better to implement the allocation process as a claim for revenue share issued by stake holder from the client side in a batch, iterating over revenue events sorded incrementally and cutting share of each event one by one;

Cases of branch winner and sales channel are safe to implement as deferred transactions, but it is better to register revenue events for them too and to issue deferred transaction for recorded events with resend ability.

[cptn-solo]

Implementation notice
To avoid need to generate detailed "billing" record for each revenue event, generated by levels, current implementation relies on incremental approach: each time branch is tipped by some revenue event (unjail, etc.), its total revenue field appended and tipprocessed flag set to false. This current 'Branch::allocateRevshare' method does the processing of revenue event and resets the flag back to true upon processing is complete.
Allocation itself relies on values of already processed (allocated) revenue stored in the branch data.
Claim process in its turn relies on values of already claimed revenue stored in the stakeholders ledger (see Stake namespace).
Some minor drawbacks of the implementation:

• if revenue events will occur often, branch state will stay "unprocessed" most of the time.
• to "process" the branch after revenue event, one should call revshare action to create deferred processing transaction for unprocessed branches.

Despite of these drawbacks, stakeholders can claim their revenue once per day/week/month, while revshare action can be called by any account even not registered in the game contract as a player.