feat: [IC-272] canister logging

[maksymar]

This PR introduces the API changes needed to support MVP for canister logging.

[mraszyk]

Will ic00.canister_status return log visibility of the canister?

[mraszyk]

I suppose that logs produced during install_code will also be recorded, right?

[maksymar]

I suppose that logs produced during install_code will also be recorded, right?

since this is an update call, then it's one of the requirements from the design doc:

Developers are able to log messages in:

• Heartbeats
• Timers
• Pre/post upgrade and canister_init
• Update calls
• Queries if called in replicated mode

[maksymar]

hi all, the feature is going to be available on the next dfx release, I suppose we can move forward with merging this PR.

please take another look and LGTM!

[Dfinity-Bjoern]

In the Interface Spec meeting, we suggested that we may want to mark this feature as experimental.

[Stefs-2142]

Really looking forward to this feature!

[mraszyk]

Why are we ignoring many cases of HypervisorError here? I also wonder if a trap log message should describe what ApiType trapped (in particular, in light of RUN-957).

[maksymar]

Why are we ignoring many cases of HypervisorError here?

because by design doc we only log debug_prints and traps. all the other HypervisorError's are specific to wasm execution, eg. Wasm engine errors, message rejected, invalid wasm, etc.

[maksymar]

I also wonder if a trap log message should describe what ApiType trapped (in particular, in light of RUN-957).

we wanted to keep it simple at the beginning with just adding a [TRAP]: prefix. it can be extended later to the method/args/api_type etc.