feat: CON-1718 Introduce Proposal to set Default Initial DKG Subnet

[eichhorl]

Background

#9782 introduced the ability to route SetupInitialDKG requests (caused by subnet creation/recovery/splitting) to arbitrary subnets, instead of always handling them on NNS.

This was done by extending proposal payloads to create/recover/split/rent a subnet with an optional SubnetId field, to which the request should be routed.

Proposed Changes

The approach above delegates the responsibility of choosing a suitable subnet to the proposer, which is brittle and difficult to test.

Instead, this PR introduces a registry key holding a "default initial DKG subnet" to which all SetupInitialDKG requests should be routed, unless specified otherwise by the proposal payload.

In particular, we:

• Introduce a new proposal to set/unset this new registry key
• Add ic-admin support to submit the proposal and query the current default subnet
• Add a registry invariant that the default initial DKG subnet must exist
• Populate the default initial DKG subnet in the replicated state's NetworkTopology based on the value in registry

Note that it must still be possible to override the default initial DKG subnet (at least as part of the recovery proposal), for the case that the default DKG subnet is the one being recovered.

Future Work

Extend the create_subnet system test to include a default initial DKG subnet, once the functionality is supported by mainnet NNS canisters.

[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. Changelog updated
2. No breaking changes
3. No data migration needed
4. No security review needed

[michael-weigelt]

Core protocol lgtm