feat: allow direct changes to the subnet admins for cloud engines

[NikolaMilosa]

This PR extends the functionality of changing direct subnet admins directly for cloud engines if the caller is among the engine admins already.

[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

No breaking changes, updated the unreleased_changelog.md

[schneiderstefan]

Two high-level question/concerns:

• If there are multiple subnet admins then they can kick each other out. Is that a problem, e.g. because the console is a subnet admin in addition to the engine creator?
• If there is rate-limiting on these endpoints then that should be fine, but I don't see any. I thought Dimitris added rate-limiting, but maybe that was a different endpoint? Without rate-limiting, this would allow an engine owner to spam the registry, something we cannot allow.

[NikolaMilosa]

Rate limiting is already implemented here.

As for overriding: if done directly (via icp-cli for example) then yes. In our code we will most likely prevent this, or leave it in, because it should be possible to move an engine from one owner to the other.

In general: most of our users will probably have only one principal alongside the controller.

[schneiderstefan]

Rate limiting is already implemented here.

Ah perfect, that was the line I didn't find.

The other was more of an FYI, i.e. we have to be aware of the pitfalls when allowing multiple subnet admins.

[daniel-wong-dfinity-org]

Hmm. Maybe we do not want to allow this? If someone does this, is there any way to get out of the "no admins" state??

Ditto for remove that results in no admins.

[NikolaMilosa]

I am not sure. I think that a regular update subnet proposal would cover it, but I am not sure. We are missing some pieces where we would deem one user an owner and ideally it would be separate from admins. Owner then could not be removed or changed easily. But that is beyond this. I will leave this discussion open.

[NikolaMilosa]

I have added the check for making the list empty for both Clear and Remove for cloud engines at least.

One thing to note:
The subnet_admin will be a derived principal id that our backend gets when a user creates the engine. This means that the principal id will not be the same for them and for the subnet admin and only their principal through our backend would generate the same derived principal meaning that it won't be callable outside our app.

There is a different path though:
If someone creates and engine subnet without our tool than they can do whatever they want. Not sure how fix that part with the model we have. We can somehow deem subnet_admin[0] as an owner, but that seems like hacking to me. Maybe we would have a proper engine_owner or something.