Fixes various clippy lints throughout the repository.

My reasoning with making all the members private on events is because there's a configuration of the type which is invalid. Thus, we really shouldn't ever let it be constructed in an invalid state. I don't see a need for the type to not be immutable also, so it should be fine.

Bring build process up to date with cover compliance and 0.9.3

• move canister types to rust
• rename (ic-history-* -> cap_*) canisters and packages
• update wasm import paths
• remove build.js
• update CI

Why?

On the integration of the Cap Motoko Library (PR https://github.com/Psychedelic/cap-motoko-library/pull/2), it was noted a few issues which can be verified by the long discussion here (https://discord.com/channels/837010835423494144/887363387909079062/921435040297140275), you might have to scroll up early on the day to find about more.

While this might not be the appropriate approach, it should expose an issue where the process differs from the Rust library for the same effects on using Cap Service (described at a higher level here https://discord.com/channels/837010835423494144/887363387909079062/921421065849294888):

Bear in mind, that the process might have changed slightly from the time this was originally written down in the Discord channel:

Rust
  - Creates router actor
  - declares create_settings paramters
    - sets controller as router id
  - checks if get_token_contract_root_bucket by app id to find root
    - otherwise
      - creates canister with create_settings as arguments and creation cycles
      - the created canister id is used by a router.install_code
  - gets the root id

Motoko
  - creates router actor
  - check if get_token_contract_root_bucket has app id to find root
  - if available, updates main root bucket
    - otherwise
      - creates settings var where controllers is router id
      - add cycles
      - calls ic management create_canister using the settings var for root canister
      - creates router actor, for some reason...
      - calls router install_bucket_code where canister is the created root canister
        - fails at this point here
      - call router get_token_contract_root_bucket
      - gets the root id

How?

The controller verification in the install code handler, takes into account the canister id of the token contract; Thus, excludes it from the verification and fallback to throwing the exception when there's more then one controller, as originally asserted. If questioned, then you are being advised to read the discussion in the Discord channel (will have to scroll up from the point/url shared above) to see the examples and tracing of the issue - bare in mind that this takes a given amount of personal effort, so its easier to follow what was written and shared, as otherwise will take time to get to that point from memory.

Notes?

⚠️ Important: should be noted that the latest in Cap (https://github.com/Psychedelic/cap) is broken, that is, the Cap Service does not build or deploy locally; while this was not verified against Rust updates, etc, it was noted while working from the branched version we can see here (https://github.com/Psychedelic/cap/tree/fix/cap-motoko-library-integration-amends) branched from ad3272da7 (https://github.com/Psychedelic/cap/tree/ad3272da7b7669671471f288c4b47e7ffe9a20db).

Why?

The dfx.json should have the fleek testnet, as it'll be required for automating deployments e.g. staging https://github.com/Psychedelic/nft-marketplace-fe/pull/71 which depends on this PR

How?

• Add feek testnet network to dfx.json

Once we switch to use certified-vars, this custom serialization logic won't be needed anymore, but for now it's okay although I don't really like how it looks atm.

This adds the missing support for booleans in the DetailValue and removes the Status, if there is a use case like XTC they can have a failed = True in details

Fixes a some clippy lints, there isn't anything to review really. I just wanted to get @qti3e's approval instead of just committing to main.

It's going to fail CI because one of the lints is on some code with a TODO annotation.

Hi, in this function "async fn deploy_plug_bucket(contract_id: Principal, cycles: u64) {" the input parameter 'contract_id': Is it a canister id or plug address?

In this function you use the unsafe keyword for almost the entrie function body.

We need to mark unsafe operations more precisely using unsafe keyword. Keeping unsafe blocks small can bring many benefits. For example, when mistakes happen, we can locate any errors related to memory safety within an unsafe block. This is the balance between Safe and Unsafe Rust. The separation is designed to make using Safe Rust as ergonomic as possible, but requires extra effort and care when writing Unsafe Rust.

@qti3e Hope this PR can help you. Best regards. References https://doc.rust-lang.org/nomicon/safe-unsafe-meaning.html https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

This PR should be merged after a full round of testing.

This PR adds enhancements to the cap's root bucket canister, to limit its outgoing requests to cap's router canister in order to increase security. It also lays the foundation for rate limiting root buckets by default. No more work has been done there on that front since it should be its separate PR.