refactor(ic-admin): [CON-1637] halt a subnet without necessarily provisioning SSH keys

[pierugo-dfinity]

This PR changes the arguments ssh_readonly_access and ssh_node_state_write_access in ic-admin's ProposeToTakeSubnetOfflineForRepairsCmd command to be optional. This allows to halt the subnet without provisioning SSH keys as suggested in the PR introducing the command. This allows to replace all halting commands inic-recovery with this one. This PR also addresses Leo's other comments in the linked PR.

Behavioural changes/remarks:

• It was not and still is not possible to halt the subnet while provisioning an empty list of SSH keys, i.e. clearing the current list. You can either overwrite the list with a non-empty list or (thanks to this PR) do no change. I cannot think of any realistic use-case for overwriting with an empty list so this should be fine (note that this is a limitation from ic-admin, this is still possible through a direct call to the governance canister's SetSubnetOpereationalLevel).
• Unhalting will now always clear the list of SSH keys. In particular:
  • App subnet recoveries' Unhalt step will clear the list instead of overwriting it with a singleton empty string (this is actually an interesting artifact that you can deduce that a subnet was previously recovered by checking whether its SubnetRecord::ssh_readonly_access field is [""] instead of []).
  • When unhalting the source subnet in subnet splitting, the list will be cleared instead of doing no change (see change in subnet_splitting.rs. This is actually probably the intended effect, which ensures that the SSH readonly key that was deployed to the subnet is cleared.
  • As a (maybe unintended) side-effect, this will also clear the list in the destination subnet, which could have been non-empty when creating the subnet, but again I doubt this corresponds to any realistic scenario.

[pierugo-dfinity]

I removed this argument just for consistency with the signature of unhalt_subnet because it was not used anyways. If we'd ever want to set some keys while halting the subnet, we could re-introduce the argument at that moment.

[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 canister behavior changes.