Add support for the delayed upgrade

[karim-en]

Implement #20

Added apis:

- up_storage_prefix();
- up_get_delay_status(&self) -> UpgradableDurationStatus;
- up_init_staging_duration(staging_duration: near_sdk::Duration);
- up_stage_update_staging_duration(staging_duration: near_sdk::Duration);
- up_apply_update_staging_duration();

Added storage keys:

- "StagingDuration":  to save the delay duration of deploying staged code.
- "UpdateStagingDuration": to save the staged delay duration update.
- "StagingTimestamp": to save the allowed timestamp to apply the staged duration or code.

[karim-en]

How about introducing helper functions for storage writes too? It’s a nit, but I think it would improve readability.

#[inline]
fn up_set_duration(key: __UpgradableStorageKey, duration: &near_sdk::Duration) {
  near_sdk::env::storage_write(self.up_storage_key(key).as_ref(), duration.to_be_bytes());
}

// Same for `fn up_set_timestamp`.

These functions would be the counterparts of up_get_{duration, timestamp}.

Please remember to update the Upgradable section in the root README.

fixed in : 6489041834e6f7040f583b6795f15eebfc4cee30 3a1f09ae8c752f110adc5a8e3db688cc63a18781

[karim-en]

How about using the term delay instead of staging duration in the code? I think that could make things clearer, for instance:

fn up_stage_new_delay(&self, delay: Option<near_sdk::Duration>);

// instead of

fn up_stage_update_staging_duration(&self, staging_duration: Option<near_sdk::Duration>);

There are events for StageCode and DeployCode.

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L90-L95

https://github.com/aurora-is-near/near-plugins/blob/6489041834e6f7040f583b6795f15eebfc4cee30/near-plugins/src/upgradable.rs#L110-L115

I think it would make sense to also have events like StageDelay and SetDelay

The term staging duration is already used in the NEP, NEP implementation, so I am skeptical about adding new terminology