feat: Add types for canister snapshot visibility settings

[gregorydemay]

Add the types needed for canisters' snapshot visibility settings, to allow principals other than the canister's controllers to be able to list and read canister's snaphots. In short this is like log visibility settings but for canister's snapshots. This PR only adds the needed types and does not change any existing logic.

Support for snapshot visibility settings for NNS-owned canisters will be done in #9257. Note that the changes regarding the CMC are needed in this PR because the CMC exposes ic_management_canister_types_private::CanisterSettingsArgs via the type CreateCanister which is an argument of the create_canister endpoint and the test test_candid_interface_compatibility ensures that the exposed Canister API is equal to the one declared in cmc.did.

Sequence of PRs to implement canister snapshot visibility settings as specified in dfinity/portal#6195:

1. refactor(exec): General-purpose visibility settings #9155
2. feat: Add types for canister snapshot visibility settings #9158 (this)
3. feat(exec): List and read canister snapshots according to new visibility settings #9227

[github-actions]

This pull request changes code owned by the Governance team. Therefore, make sure that
you have considered the following (for Governance-owned code):

1. Update unreleased_changelog.md (if there are behavior changes, even if they are
   non-breaking).

2. Are there BREAKING changes?

3. Is a data migration needed?

4. Security review?

How to Satisfy This Automatic Review

1. Go to the bottom of the pull request page.

2. Look for where it says this bot is requesting changes.

3. Click the three dots to the right.

4. Select "Dismiss review".

5. In the text entry box, respond to each of the numbered items in the previous
   section, declare one of the following:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

Brief Guide to "Externally Visible" Changes

"Externally visible behavior change" is very often due to some NEW canister API.

Changes to EXISTING APIs are more likely to be "breaking".

If these changes are breaking, make sure that clients know how to migrate, how to
maintain their continuity of operations.

If your changes are behind a feature flag, then, do NOT add entrie(s) to
unreleased_changelog.md in this PR! But rather, add entrie(s) later, in the PR
that enables these changes in production.

Reference(s)

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

Updated CMC unreleased_changelog.md.

[mraszyk]

DSM changes look good to me. The NNS changes are likely accidental here and should be moved to the separate PR.

[gregorydemay]

DSM changes look good to me. The NNS changes are likely accidental here and should be moved to the separate PR.

@mraszyk The changes regarding the CMC are not accidental: they must be part of that PR because the CMC exposes ic_management_canister_types_private::CanisterSettingsArgs via the type CreateCanister which is an argument of the create_canister endpoint and the test test_candid_interface_compatibility ensures that the exposed Canister API is equal to the one declared in cmc.did. Not having those changes in this PR would require a bigger refactoring in the CMC code (basically to not expose the private ic_management_canister_types_private::CanisterSettingsArgs). I will adapt the PR description.