Owner + upgrade functionality for EVM contract

[ilblackdragon]

Allows to set owner at new call and then change it.
Allows to stage new code and upgrade after 24 hours.

TODO: adding sim tests

[joshuajbouw]

I followed the dependencies to see which each of them are using and the last being bindgen v0.54.0 sets proc-macro2 which sets the version as 1 but then I realised what actually happened. A Cargo.lock was shipped in for the library. Deleting this fixes it or just simply running cargo update.

[joshuajbouw]

#65 addresses this current build issue you have. Review, pull and rebase.

[joshuajbouw]

Current issue is a plethora of, needs further investigating whats going on over there as we are getting this straight from git itself which indicates to me that cargo check wasn't ran when pushing there.

error[E0432]: unresolved import `syn::export`
 --> /home/joshuajbouw/.cargo/git/checkouts/near-sdk-rs-7ba52202f378a9d9/477056f/near-sdk-core/src/code_generator/attr_sig_info.rs:1:10
  |
1 | use syn::export::TokenStream2;
  |          ^^^^^^ could not find `export` in `syn`

[joshuajbouw]

Pinned funty here to get compiling again. v1.2.0 is broke API in parity's ETH code upon cargo update to fix another issue.

[joshuajbouw]

Needs discussion and completing.

[joshuajbouw]

Needs discussion and completing.

[joshuajbouw]

Should this be erroring?

[joshuajbouw]

Should this be erroring?

[artob]

@joshuajbouw Please sort out the merge conflict due to #65, and give me an idea about whether I should proceed to merge this as-is or you figure the sim tests will be forthcoming in short order if you're unblocked now?

[joshuajbouw]

Tests are going great and working as expected so far. I can't test the actual upgrade but everything else is tested up til this point. I am currently blocked with not being able to produce blocks which will trigger the upgrade as I need to produce a days worth of blocks: near/near-sdk-rs#320

Prior, it was based off of 24 hour waiting period but, of course, we can't -exactly- wait 24 hours for us to check if the test went through and since our block times are 1 block per second, I can instead create that many blocks in the test to trigger.

The tricky thing is that is a lot of blocks to produce. What I would suggest is to create some test methods in the WASM itself to produce a WASM test binary which allow us to alter values internally to simulate that a day has passed.

Thoughts?

[ilblackdragon]

There is a method in standalone runtime to produce a bunch of empty blocks:

    /// use near_sdk_sim::runtime::init_runtime;
    /// let (mut runtime, _, _) = init_runtime(None);
    /// runtime.produce_blocks(5);
    /// assert_eq!(runtime.current_block().block_height, 5);
    /// assert_eq!(runtime.current_block().epoch_height, 1);

If producing 86k blocks takes too long in test (I would not expect that but who knows) - let's just add the wait time as a parameter in constructor and store in storage. This way it can be configured to longer as code matures as well. Further upgrades can change that parameter on migration.

[joshuajbouw]

Right, I had to add a PR to be able to produce the blocks. I do like the idea of adding in that extra argument though for time to wait. Though, it makes me wonder what the minimum value could be. To be safe, you obviously would want at least 1 day.

[artob]

Superseded by aurora-is-near/aurora-engine#6