Simplify adoption of default security group

[jacobwinch]

In order to reduce boilerplate and enforce best practice, this library will create security groups with sensible defaults automatically whenever an ASG is instantiated. For new projects, this reduces complexity significantly. However, it poses some problems when migrating existing projects, which already have a security group defined. Although it is possible for existing stacks to override the library’s default behaviour and permanently inherit their existing custom security group, this is undesirable, as it prevents these stacks from using our standard patterns or picking up future improvements easily.

Unfortunately, it is not possible to replace a stack’s security group in a single CloudFormation update without introducing downtime. Attempting to add a new security group and delete an old security group in a single operation fails because the old security group still contains running instances. In order to replace a security group with the default provided by this library the following steps must be performed in sequence:

1. Initial cdk template definition:
   1. Ensure that an ASG is instantiated. Allow the ASG to create its own security group i.e. do not link the old security group to the ASG via the securityGroup prop
   2. Ensure that all of the required ingress/egress rules are applied to the new security group (the defaults provided by GuAutoScalingGroup may not be sufficient for all use-cases)
2. Instantiate the old security group separately from the ASG, ensuring that overrideId: true is set.
   1. Add the required ingress rule manually - the old security group must retain an ingress rule allowing traffic from the load balancer, so that instances in the old security group can still serve requests during the upgrade.
3. Generate a new CloudFormation template using cdk (for some projects, this will happen automatically as part of CI)
4. Update the CloudFormation stack (for some projects, this will happen automatically as part of the Riff-Raff deployment in the next step)
5. Re-deploy using Riff-Raff. When new instances are brought up, they will be associated with the new security group. The old instances (still associated with the old security group) will be terminated, freeing up the old security group for deletion
6. Update cdk template to remove the old (and now unused) security group and the associated rule additions
7. Generate a new CloudFormation template using cdk (for some projects, this will happen automatically as part of CI)
8. Update the CloudFormation stack (for some projects, this will happen automatically as part of the Riff-Raff deployment in the next step)
9. Re-deploy using Riff-Raff
   1. Confirm that everything still works as expected

The cdk changes outlined above are time consuming and error-prone. If steps are omitted, or performed in the wrong order, downtime may be incurred. Consequently, we would like to simplify the process of replacing existing security groups via the library. Unfortunately this migration will still need to happen via two separate CFN updates / PRs, but each code change could be made much more straightforward.