Implement generational storage with SELFDESTRUCT tests

[mfornet]

Check state is removed after selfdestruct is called following this description:

https://gist.github.com/mfornet/a8ffcedfffd22612e34cf0b3c3f5c9e3

@joshuajbouw use this test, to check that reset state is working.

---

Also add a test (test_self_destruct_with_submit) where function that call selfdestruct is called using engine.submit rather than engine.call and it fails with:

`Result::unwrap()` on an `Err` value: InconsistentStateError(IntegerOverflow)'

This was found by chance. @birchmd @artob can you take a look at this.

[joshuajbouw]

Hm, getting an error that I'm missing a file? Can you double-check that it's pushed?

Can see the issue here: https://github.com/aurora-is-near/aurora-engine/pull/84/checks?check_run_id=2572055068#step:6:1400

    pub fn load() -> Self {
        Self(solidity::ContractConstructor::compile_from_extended_json(
            "etc/eth-contracts/artifacts/contracts/StateTest.sol/SelfDestructFactory.json",
        ))
    }

[birchmd]

Hm, getting an error that I'm missing a file?

Looks like it's supposed to be generated by yarn (see changes to Makefile). We'll just need to update the GitHub action to run that first.

[birchmd]

By the way @mfornet is yarn (or hardhat or whatever) needed to compile this contract for some reason? If this existing solidity::compile function would work (as is used for the standard precompiles test) then I would prefer that to adding an additional tooling dependency.

Even if yarn is needed we could probably use a similar tactic to what I used with the standard precompiles contract to get rust to call yarn itself rather than have it go through the Makefile. This would be a better way than what I suggested about about changing the GitHub action.

[birchmd]

called using engine.submit rather than engine.call and it fails

Noted. I'll look into it.

Update: I know what is throwing the error. It has to do with storage management in the near-vm-runner. You can see the error being created when you evict storage that somehow was not accounted for: logic.rs#L2125. I can make the error not happen by increasing current_storage_usage in the initial Context for AuroraRunner. I think what I should do is update the context after each run call. I'll submit a PR to do that.

[joshuajbouw]

Got it now @birchmd

[birchmd]

@mfornet the error you encountered with submit is fixed in #85

[artob]

@joshuajbouw @mfornet Please resolve the conflicts now after the merge of #87.

[joshuajbouw]

Just merged develop into this branch carefully as there were at least 20 file conflicts.

[joshuajbouw]

Generally fine, I still have to wait for the CI to go through its run, but my only complaint is that there is obviously quite a bit of feature creep going on here. Do be very careful with that going forward. Would be best to have each of those as separate PRs. Also, do thoroughly document all changes that had been made in the description.

[mfornet]

Found a subtle bug in the way keys were created. Some tests are still failing (see CI), and is a regression introduced in PR #87, already checked on previous commit that it was working fine.

I was looking into it, but still haven't figured out the issue.

Simple test where it fails

1. A standard ERC20 implementation (form OpenZeppelin) is deployed.
2. Check balance from a user (it is 0)
3. Mint 10 tokens for the user
4. Check balance from a user (it is 10)

At step 3 the transaction fails.

[birchmd]

Great work team!