feat: CON-1716 Allow SetupInitialDkg requests to be answered by subnets other than NNS

[eichhorl]

Background

SetupInitialDkg is a management canister call that can only be made by canisters residing on the NNS. Typically, this management canister call is triggered by proposals that create or recover a subnet. Similarly, it will also be used to create cloud engines.

Upon receiving such a SetupInitialDkg request, the receiving subnet will perform two instances of the NiDKG protocol. The result yields the key material of the new or recovered subnet, from which also the subnet ID is derived.

Problem

Today, SetupInitialDkg requests are exclusively handled by the NNS subnet. This has some disadvantages, which are exacerbated by the advent of cloud engines:

1. The code implementing the remote NiDKG protocol exclusively runs on NNS.
2. The protocol is comparatively expensive and puts some load on the NNS.
3. So far, execution of this management canister call was gated by proposals. This may no longer be the case for cloud engines.
4. When handled on the NNS, cloud engine creations compete for the same resources as critical recovery proposals.
5. Problems surfacing on the NNS subnet may have higher impact compared to other subnets.

Proposed Solution

Instead of always handling SetupInitialDkg request on the NNS, this PR proposes the ability to optionally specify the subnet to which the request should be routed. Specifically, this would allow the key material for cloud engines to be created on a different subnet than the one handling critical recovery proposals.

To do this, we extend the SetupInitialDKGArgs (and consequently, the Create/RecoverSubnetPayload) with an optional SubnetId field, to which the request will be routed.

Note that, although these changes have not been deployed to the mainnet NNS canisters yet, system tests using mainnet NNS canisters already pass. This is because the new argument is still ignored by the mainnet canisters, which means they fall back to the old behavior (SetupInitialDkg is routed to the NNS).

Future Work

• Notify dashboard teams of the new arguments added to create and recover subnet proposals.
• Select a designated SetupInitialDkg subnet for handling Cloud Engine creations, for instance the II subnet.

[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

1. Done.
2. No breaking changes.
3. No data migration needed.
4. No security review needed. Conceptually this is analogous to ReshareChainKey requests being routed to the II subnet during subnet creations/recoveries, which is done to reshare an ECDSA/Schnorr/Vetkd key at the same time.

[daniel-wong-dfinity-org]

👍 for Governance.