feat(boundary): setup of rate-limit canister

[nikolay-komarevskiy]

This MR sets some boiler plate code for the rate-limit canister:

1. Rust candid types are stored in rs/boundary_node/rate_limits/api as a lib crate. This allows to reuse this interface e.g. in the canister-client (4).
2. Code of the canister is organized in ic/rs/boundary_node/rate_limits/canister (as a lib crate) and implements one function get_config() from the candid interface.did. Canister uses one variable stored in the stable memory for testing.
3. dfx deployment of the canister can be done with dfx deploy rate_limit_canister --network playground --no-wallet
4. Minimal canister-client to interact with the deployed canister. Note: copy canister ID from the previous dfx command

[rikonor]

I see that you have a lot of

type XResponse = variant {
  Ok;
  Err: text;
};

maybe it'd make sense to consolidate those somehow?

[nikolay-komarevskiy]

These types could be consolidate at some later point. But once consolidated the extensibility/flexibility is lost. Probably some Ok variant will contain messages, i haven't yet carefully thought through.

[rikonor]

Yes, but couldn't that just be a new Response type? I didn't mean you can only respond with this smaller type. E.g

type EmptyResponse = variant {
  Ok;
  Err: text;
};

type ListResponse = variant {
  Ok: vec RuleId,
  Err: text;
};

service: {
  disclose: (DiscloseArg) -> EmptyResponse;
  list: (ListArg) -> ListResponse;
};

[rikonor]

Should it be possible when specifying rules to also specify whether they are public or not? Or do you have to basically set the config, and then in another call disclose rules? I guess what I'm asking is "what does a normal user flow look like?"

[nikolay-komarevskiy]

The expected flow is:

1. Each newly added rule is confidential by default
2. To open the rule for public viewing a separate call to disclose_() function is needed
   We could indeed add an additional field policy with private/public, but it seems to be unnecessary. If needed it can be added.

[rikonor]

Any thoughts on consolidating these two disclose methods? e.g

type DiscloseArg = variant {
  Rules: vec RuleId;
  Incidents: vec IncidentId;
};

disclose: (vec DiscloseArg) -> (DiscloseResponse);

and similarly for get_rules:

type ListArg = variant {
  Rules: vec RuleId;
  Incidents: vec IncidentId;
};

list: (vec ListArg) -> (ListResponse);

[nikolay-komarevskiy]

I do like the disclose one! but for get_rules it would be strange as for a RuleId it returns a single rule.

[rikonor]

Friendly suggestion - you may not agree with it. Notice that canisters don't really have a main function, so it's hard to gauge "what runs first". This can make it tricky to have a clear understanding of the order of operations happening in the canister upon startup (the various initialization steps, like declaring stable memory, canister methods, etc). For that reason, my suggestion would be to not rush to break up the canister code into separate files. Instead, treat canister/lib.rs similarly to how you would treat your main.rs file, meaning configure all your initialization logic there sequentially, like you would do in a main function. So in this case:

# lib.rs

... define stable memory

... define dependencies that will be used in your canister methods

... define canister methods

then on a per-need basis you'd create new files to host things that get imported into your lib.rs. All this is mostly so that it's easier to understand the flow of the canister. As it is right now, you would have to ask yourself, what's happening first? Stable memory in storage.rs? Canister methods in canister.rs?

[nikolay-komarevskiy]

Notice that canisters don't really have a main function, so it's hard to gauge "what runs first".

Yes, canister is an actor.

For that reason, my suggestion would be to not rush to break up the canister code into separate files.

I understand. Since I have already prototyped the canister locally, i wanted to have at least a minimum separation of files. For example canister/types.rs and canister/canister.rs (lib.rs) make sense already now IMO. Stable memory variables and init i can add in the next MR. Wdyt? However, I still wanted a working canister at this point.