fix!: avoid deploying a contract to an account with existing state

[esaminu]

This PR addresses near/near-wallet#2261 and avoids bricking accounts with arbitrary contract state left over by doing the following:

• The disable 2fa procedure will clear all contract state after itself in 2 atomic steps:

  1. Clear all requests by calling delete_request to ensure that the rpc view_state call needed to use the state cleanup contract's clean method does not throw a TOO_LARGE_CONTRACT_STATE error due to the state size limit.
  2. Deploy of the state cleanup contract passed as an argument and call the clean method in the same transaction as the standard key deletion and conversion steps and finally deploy of the 'empty' contract that is passed as an argument.

• The enable 2fa procedure will submit a transaction that will always fail designed to identify the current state of the contract it is interacting with. The transaction has 2 actions, one that deploys the multisig contract and the second calls delete_request with the request_id argument set to u32::MAX.

  • If the transaction throws a 'No such request' error, we know that the state in the contract is valid multisig state and we proceed with the enable 2fa operation.
  • If the transaction throws a 'Multisig contract should be initialized' error, we know that we are dealing with a contract that has no state so we proceed with the enable 2fa operation adding a new function call at the end of the action batch.
  • If the transaction throws a 'Cannot deserialize the contract state' error then we know the contract we are dealing with has arbitrary contract state and we abort the operation throwing a contractHasExistingStateError.
  • If the transaction throws any other error, then we abort, throwing that error.

This was tested with different combinations of contract states and code_hashes here

[frol]

This is currently blocked due to view_state requests having a limit and not being paginated.

@bowenwang1996 Is there a chance that fetching a list of state keys can be faster than fetching the key-values?

[bowenwang1996]

This is currently blocked due to view_state requests having a limit and not being paginated.

@bowenwang1996 Is there a chance that fetching a list of state keys can be faster than fetching the key-values?

I don't think so, at least with the current implementation

[MaximusHaximus]

Nice work on identifying all of the underlying behaviours we've been encountering with this logic 💖 Added a few questions/concerns in-line...

[MaximusHaximus]

We're just about there - just a few things in-line and then we can get this landed 👍 <3

[MaximusHaximus]

👍 nice work! Excited to get this landed :)