Refund user when ExitToNear promise fails

[birchmd]

Closes #269

The solution we agreed on was the one suggested by @mfornet where we change the ExitToNear precompile API to accept an address to refund the assets to in case the exit promise fails. This is a breaking change, however, to allow this PR to be merged without breaking anything the API change is hidden behind a compile-time feature flag. @mfornet @sept-en and I will need to coordinate on migrating the existing bridged ERC-20 assets and enabling this feature. After this feature is enabled by default then we can clean up the code to remove the old logic.

This PR is relatively large, so guide the reviewer I draw your attention to the following pieces:

• The main logic change is of course in engine-precompiles/src/native.rs; the refund itself happens in the new function in engine/src/lib.rs
• I've added a few new tests to engine-tests/src/tests/erc20_connector.rs, however because these tests rely on resolving promises they could not use the AuroraRunner testing utility which existing tests used. Therefore, there is a great deal of boilerplate code added as well to wrap up near-sdk-sim calls. I recommend simply focusing on the tests themselves (in particular the assert statements show how the balances behave with and without this refund mechanism).
• The whole test suite passes with and without the new feature enabled. You can check this locally but running make check and make check error-refund=yes. As a sanity test you could also check locally that various tests fail if you do not consistently enable the feature (i.e. if you compile the contract with the new feature, but then run the tests without it or vice versa).
• There are two "new" solidity contracts, but really they are the old contracts with small modifications for the API change. Unfortunately I do not know if conditional compilation is a thing in solidity, so I had to duplicate the whole contract. Below is the diff

$ diff etc/eth-contracts/contracts/test/Tester.sol etc/eth-contracts/contracts/test/TesterV2.sol
6c6
< contract Tester {
---
> contract TesterV2 {
44,45c44,46
<         bytes memory input = abi.encodePacked("\x00", recipient);
<         uint input_size = 1 + recipient.length;
---
>         address sender = msg.sender;
>         bytes memory input = abi.encodePacked("\x00", sender, recipient);
>         uint input_size = 1 + 20 + recipient.length;


$ diff etc/eth-contracts/contracts/EvmErc20.sol etc/eth-contracts/contracts/EvmErc20V2.sol
15c15
< contract EvmErc20 is ERC20, AdminControlled, IExit {
---
> contract EvmErc20V2 is ERC20, AdminControlled, IExit {
52c52,53
<         _burn(_msgSender(), amount);
---
>         address sender = _msgSender();
>         _burn(sender, amount);
55,56c56,57
<         bytes memory input = abi.encodePacked("\x01", amount_b, recipient);
<         uint input_size = 1 + 32 + recipient.length;
---
>         bytes memory input = abi.encodePacked("\x01", sender, amount_b, recipient);
>         uint input_size = 1 + 20 + 32 + recipient.length;

[joshuajbouw]

Adding comments for now, I'm going to need a fresh start in the morning to go through this.

[birchmd]

@mfornet there are tests that depend on the specific format of this log. Do we use it in production as well? If not I will change to harmonize with other logs (ie underscores in the label and only space (no colon) as the separator with the value).

[mfornet]

Let's change them to fit the guideline

[mfornet]

Thanks for PR, and sorry for late review. Everything is good here.

What is the plan ahead regarding upgrades to the ERC20 contracts 🤔 . The two paths ahead I'm seeing are:

• Deploy the new contract on the old address.
• Deploy the new binaries on different address; move all balances from one to the other; update the erc20-nep141 mapping.

The first one is easier, but I'm concerned about this breaking some assumptions about how this particular tokens were deployed. What do you think?

In any case we should plan ahead, and have this contracts to be upgradable. So in case we need to do an upgrade in the future it is easier. We can set the owner to be aurora account. This is not blocking this PR.

[birchmd]

Thanks for PR, and sorry for late review. Everything is good here.

What is the plan ahead regarding upgrades to the ERC20 contracts 🤔 . The two paths ahead I'm seeing are:

• Deploy the new contract on the old address.
• Deploy the new binaries on different address; move all balances from one to the other; update the erc20-nep141 mapping.

The first one is easier, but I'm concerned about this breaking some assumptions about how this particular tokens were deployed. What do you think?

In any case we should plan ahead, and have this contracts to be upgradable. So in case we need to do an upgrade in the future it is easier. We can set the owner to be aurora account. This is not blocking this PR.

I'm not sure which is the better option. Perhaps @sept-en would like to weigh in.