Feat: `pallet-pool-system` - Decouple Cash-Inflow from Epoch-Execution

[mustermeiszer]

Description

Some pools in system have a cash flow issue with the current epoch design.

Why
A pool invests into other assets. Those assets have a monthly liquidity. Meaning, redeeming and investing into such assets is only possible once per month. Also, correct pricing for said assets is also only given at said moment. In our system a pool needs to know the correct prices for assets first, close an epoch and afterwards it receives the new investments. I.e. receiving of investments happens at the same time as pricing of assets - from an epoch perspective.

Problem
The above would have a cash-drag of one month for all new investments, because it would be necessary to transfer the new investments to another party BEFORE receiving the prices for the assets, which is technically not possible at the moment.

Solution

• Epoch closing already transfers ALL tokens to the pool-system -- increase reserve too, NOT block withdraw() from pool, adapt EpochExecutionInfo to not contain the pool state but rather all relevant information to execute the epoch on the most recent state
• NO trying to execute epoch during closing anymore -- seperate close() and execute()
• Epoch execution does take the most recent state state and tries to execute with the given solution - might default to full fulfillment if no solution is available
• Epoch execution re-transfers non-executed amounts back -- best taken care of by pallet-investments to not couple those too

APPS

• NEED to inform apps about the api-change of closing an epoch

Research/based on

• Issuer needs

How will this affect the code base

• More flexible epoch structure
• Remove storage and complexity of handling snapshot at epoch closing vs. state during epoch execution

What are foreseen obstacles or hurdles to overcome?

• Epoch executing needs to back-transfer un-fullfilled tokens → if not possible, pool is blocked wrt. to new investments
• Pallet-investments needs changes to transfer the tokens already during processing and re-get the tokens during fulfillment