feat: Implement heartbeat support

[ninegua]

Closes #2728

• Basic support for heartbeat as a system function
• Proper async type and type checking of the heartbeat function
• Test cases

[ninegua]

At the moment it seems to work. But I am trying to change heartbeat to return () instead of async (), then I got this error:

+heartbeat.mo:12.16-12.31: type error [M0037], misplaced async expression; try enclosing in an async function

Not exactly sure how to proceed. So I'm asking help from @crusso

[crusso]

I pulled your branch locally and played around with changing the return type to (), but couldn't quite make it work.
The type-checking changes were easy, but it falls over in the backend for some inscrutible reason.

To do that, you'd really want the heartbeat to be a shared oneway function so your example would wind up looking something like this:

import Prim "mo:⛔";

actor {
  var count = 0;
  public shared func inc() : async () {
    count := count + 1;
    Prim.debugPrint("count = " # debug_show(count));
  };

/*
  system func heartbeat() : async () {
    if (count < 10) {
      Prim.debugPrint("heartbeat");
      ignore inc();
    }
  };
 */

  system shared func heartbeat() : () {
     ignore async {
      if (count < 10) {
        Prim.debugPrint("heartbeat");
        ignore inc();
      }
    }
  };

};

Looking at that now, I'm not sure that's preferable to just declaring the async () type and using a local function.

I think you're lowered code might actually fail to type check once you extend check_ir.mo to check the heartbeat expression. The function call probably needs an instantiation at type T.Any (there's a phantom parameter there).

[crusso]

I've made the IR typeable, but I'm still a little worried that this code will have the hearbeat message generating a response, even though the spec says a heartbeat message cannot reply or reject. I guess that might generate a silent trap at the end of the heartbeat message or maybe the ic-ref and the replica aren't actually enforcing this (or I misread the spec)

[crusso]

Note to self: the way to fix this is probably to introduce a new CallHeartbeat primitive that passes dummy success/fail continuations (instead of ones that reply/reject).

[crusso]

Another small issue with this PR is that I believe it always exports the hearbeat method, even if it has trivial work. That's probably not what we want since every Motoko canister will no opt in to hearbeat notification, stressing the heart as it were.

[crusso]

Apart from the issue of always registering a heartbeat, I think I've convinced myself that this code is actually ok. I was worried it was attempting to reply or reject, but in fact, it just calls the helper method and discards it, without every registering a reply/reject continations which is probably ok - the body will run asynchronously but never respond.

[crusso]

I've redone a bit of the lowering/codegen and added some documentation. @ninegua PTAL if you care, otherwise I'll defer to @chenyan-dfinity or @ggreif for review.

(This implementation will do an extra async call for each heartbeat, but that's really a problem with our implementation of async functions and will be fixed by fixing that. I didn't have the stomach to circumvent this by adding a hack. An alternative would be to also support ()-returning heartbeats that are executed inline, but cannot send, but that seems gross too).

[crusso]

@ninegua I seem to have confused git with my inept merging of branches - sorry about that.

[crusso]

PR moved to #3039 to improve perf of CI

[ggreif]

As #3039 has landed, I think this can be closed now.

[ggreif]

Please reopen if something is still missing.