feat: Unify ic-cdk to v0.18.6

[lwshang]

This PR unifies the ic-cdk dependency to v0.18.6.

Background

A while ago, the release of ic-cdk v0.18 caused some issues. We discovered that mixing different versions of ic-cdkwithin a single canister could break execution, a problem that often occurred when a project's dependencies relied on different ic-cdk versions.

To fix this, we extracted the asynchronous execution logic into a new crate, ic-cdk-executor. As long as different versions of ic-cdk depend on the same version of the executor crate, they can now coexist. We patched older versions of ic-cdk (v0.17 and below) to use ic-cdk-executor v0.1.0, and ic-cdk v0.18 and later now use the stable ic-cdk-executor v1.0.

Because the executor crate is designed to only allow one version in a dependency tree, we're doing a one-time migration to unify all ic-cdk dependencies in the ic mono-repo to the latest v0.18.6.

Major Changes

Dependency Upgrades

• ic-cdk v0.18.6
• ic-cdk-executor v1.0.2
• ic-cdk-timers v0.12.2
• canbench-rs v0.2.1
• candid v0.10.17
• ic-canister-sig-creation v1.3.0
• ic-vetkeys 0.4.0

Wrap custom canister entry-points in executor_context

Some canister entry-points are defined using the #[export_name = "..."] annotation instead of ic-cdk macros like #[update]. The function body are now required to be wrapped in ic_cdk::futures::in_executor_context or ic_cdk::futures::in_query_executor_context. This is a replacement for the removed ic_cdk::setup().

Example:

#[export_name = "canister_query get_block_pb"]
fn get_block_() {
    ic_cdk::setup();
    ...
}

=>

#[export_name = "canister_query get_block_pb"]
fn get_block_() {
    in_query_executor_context(|| {
        ...
    })
}

Replace decoding_quota with decode_with

Example:

#[query(hidden = true, decoding_quota = 10000)]
fn some_query(arg: SomeType) { ... }

=>

#[query(decode_with = "candid::decode_one_with_decoding_quota::<100000,_>")]
fn some_query(arg: SomeType) { ... }

The entry-points using decode_with option will be rendered as blob in the auto-generated Candid interface.
To preserve the original type information, the Candid auto-generation is disabled by hidden = true. And a dummy function is added to generate the desired Candid type.

// Manually add a dummy method so that the Candid interface can be properly generated:
//   `http_request: (HttpRequest) -> (HttpResponse) query;`
// Without this dummy method, it will be `http_request: (blob) -> (HttpResponse) query;`
// because of the `decode_with` option used above.
#[::candid::candid_method(query, rename = "http_request")]
#[allow(unused_variables)]
fn __candid_method_http_request(request: HttpRequest) -> HttpResponse {
    panic!("candid dummy function called")
}

Annotate #![allow(deprecated)]

To keep this PR focused and manageable, we've used #![allow(deprecated)] to suppress warnings in files that call deprecated ic-cdk APIs. These APIs are safe to continue using for now, and this approach allows us to postpone the necessary code refactoring. The task of updating these APIs can now be handled by the respective teams that own this code.

API replacement

For files that only use a few deprecated ic-cdk APIs, we've replaced them directly. For example:

• ic_cdk::spawn -> ic_cdk::futures::spwan_017_compat
• ic_cdk::id -> ic_cdk::api::canister_self
• ic_cdk::caller -> ic_cdk::api::msg_caller
• ic_cdk::api::set_certified_data -> ic_cdk::api::certified_data_set
• ic_cdk::api::canister_balance -> ic_cdk::api::canister_cycle_balance
• ic_cdk::api::stable -> ic_cdk::stable

What's Next?

This migration provides the foundation for future work. Owning teams are encouraged to refactor their code away from the deprecated ic-cdk APIs. A comprehensive migration guide is available to assist with this process.

This is majorly a dependency upgrade. No behavior changes is expected.
We rely on existing CI to detect any regression.

[gregorydemay]

Thanks @lwshang for this huge effort!