Description

We have some users that want to prevent accidental close of the Head when non-ada assets are present in the confirmed snapshot UTxO set.

Suggested solution

• In order to do this we can introduce SafeClose input that would detect any assets that would cause the fanout transaction to fail anyway and prevent closing from happening unless the specified tokens are burned.
• Close client input would keep the same semantics and this new SafeClose would benefit the users which want to make sure the Head will be able to fanout.

This new input could also be utilized to detect other potential pitfalls like too large UTxO set in the future too.

Alternative

• Re-open a closed head #1721 - This could be used in similar scenario, where there is consensus on re-opening before fanning out. It would require a new L1 transaction.
• LambdaClose or CallbackClose what would close based on the result of calling back a supplied endpoint with the entire state of the snapshot. This could be used by clients wishing to implement their own "can I close or not" logic. In principle this doesn't make a lot of sense, because clients should already be doing this. But perhaps it's an interesting alternative?
• Close but with a prompt to give a list of all the non-asset ids; if you provide them, close anyway (knowing that the resulting head will not be able to fanout)
• Partial fanout #1468 - Should help to allow part of the UTxO state to be fanned out; i.e. depending on the UTxOs, some things can still be recovered (TBD what exactly this looks like??)

Additional context

No response