[ROSA HCP] Zero worker nodes

User Story

As a ROSA HCP cluster owner/administrator, I want to have a fully-supported ROSA HCP cluster without any worker node requirements, so that I can

• Save costs
• Have a warm-standby backup cluster
• Reduce unnecessary resource usage

Considerations

• The metric that is used for metering the control plane usage by Subscription Watch for ROSA HCP clusters will need to be updated when this functionality lands
• OAuth on CP currently relies on proxy to DP in order to access potentially private OAuth endpoints, this is a case where we just state that authentication isn't expected to work, and tell customers to use htpasswd or a publicly-available IdP
• Audit log forwarding to the DP will likely not work, and thus audit logs would be unavailable without DP, we should be notifying customers of this impact

Acceptance Criteria

• I can create an HCP cluster, day-1, without requiring a default machine pool
• I can remove all machine pools from my active cluster, day-2
• I can scale down all my existing machine pools to zero replicas, day-2
• I can create a machine pool with zero replicas, day-1
• I can create/edit an autoscaling machine pool with a zero replica minimum
• Red Hat continues to support the control plane and API SLA
• I can continue to access the API, even without any worker nodes

Default Done Criteria

• All existing/affected SOPs have been updated.
• New SOPs have been written.
• Internal training has been developed and delivered.
• The feature has both unit and end to end tests passing in all test
  pipelines and through upgrades.
• If the feature requires QE involvement, QE has signed off.
• The feature exposes metrics necessary to manage it (VALET/RED).
• The feature has had a security review.* Contract impact assessment.
• Service Definition is updated if needed.* Documentation is complete.
• Product Manager signed off on staging/beta implementation.

Dates

Integration Testing:
Beta:
GA:

Current Status

GREEN | YELLOW | RED
GREEN = On track, minimal risk to target date.
YELLOW = Moderate risk to target date.
RED = High risk to target date, or blocked and need to highlight potential
risk to stakeholders.

References

Links to Gdocs, github, and any other relevant information about this epic.