feat: OptimismPortal wd invalidation mitigation

[smartcontracts]

Introduces a proposal that would prevent user withdrawals in the OptimismPortal from being invalidated any time that the fallback is utilized.

[ajsutton]

I'm in favour of this change. The validity checks are still really simple and it gives the guardian significantly more flexibility. The concern about user impact affects the guardian decision making process even if the actual impact winds up being small so providing better tools to simplify the decision making process seems well worth it to me.

[clabby]

This looks good to me. Simple enough to change up. Also will include some changes to the deputy guardian.

[smartcontracts]

Reminder to self: do not allow invalidation timestamp to be greater than current timestamp

[Ethnical]

Agreed, and let a comment but the rest looks a nice initiative to me!

Need fresh approvals

[wildmolasses]

lgtm; looks like this doc defers on variable naming, i'll assume it comes during spec/impl phase 👍

[anikaraghu]

@smartcontracts a bit late to the game here, but wondering if there will be a way to have presigned fallbacks to the permissioned game that do invalidate all existing games (for incident response scenario). was chatting with @elihaims about this today and this could be really helpful to prevent a scenario in which we need to pause the whole bridge to remedy a widespread issue

[smartcontracts]

@smartcontracts a bit late to the game here, but wondering if there will be a way to have presigned fallbacks to the permissioned game that do invalidate all existing games (for incident response scenario). was chatting with @elihaims about this today and this could be really helpful to prevent a scenario in which we need to pause the whole bridge to remedy a widespread issue

Fallback can be triggered by the Guardian so it should be possible to have pre-signed fallbacks that do invalidate existing games. Can account for this in the spec with a function that triggers the fallback + sets the invalidation timestamp to the current timestamp (this way you don't need to know the timestamp that you'll be using ahead of time).

Worth noting that you would need to have pre-signed fallbacks that have the same nonces as pre-signed pauses, but that's fine imo.