Decoupling snapshots from transaction confirmation

[Trymyrt]

Why

The instant finality of the snapshots is a very attractive feature, however there is a rich base of use cases that would be possible if the snapshot finalization mechanism is decoupled from the transaction consensus, for example as a configurable mechanism which by default is set to every transaction.
This would enable heads to perform chained operations which should only be settled upon completion, and otherwise if the head is closed mid-chain the settled state would be rolled back to the latest agreed snapshot.
Such a feature would be instrumental to enabling features like uncollateralized lending for capital efficient liquidations, arbitrage and other.
Take for example:

A liquidation

1. A snapshot is made
2. A participant could borrow funds from a pool UTxO [tx]
3. They could repay a collateralized debt position and reclaim the collateral [tx]
4. They could swap the collateral for the debt token [tx]
5. They could repay the debt and pocket the difference [tx]
6. A new snapshot is made to finalize the flash loan cycle

If every transaction triggers a snapshot, this would be a very unsafe pattern since the borrower (assuming they are a participant in the head) could trigger a head close after step 2, 3 or 4. Whereas the CDP owner (assuming they act as a participant in the head) could try to contest transactions as well. However if the snapshots were distributed as described, interrupting the flow mid-way would in the worst case only result in a roll back to a pre-liquidation state, which could be designed around.

What

The snapshot mechanism is a very important aspect of the protocol, and is a key that could unlock a wide range of potential applications. In particular it could be separated from the transaction consensus mechanism, so that not every validated transaction triggers a snapshot.

How

This could perhaps be done by making it a completely separate subroutine, where nodes would have a separate snapshot consensus, which by default would be triggered along with every transaction validation, but could in principle be set periodically or upon mutually agreed conditions by the participants.
Alternatively there could be specific inclusion/exclusion criteria for transactions so that only a subset of transactions would trigger snapshots, or alternately that a certain subset of transactions were exempt from triggering snapshots.