Deactivate Feature Flag instance ID before deletion
Problem to solve
Born from #209214 (comment 345373684)
As a developer that has many services reaching a single feature flag project, if the instance id gets compromised, then all the services need to be updated with the newly generated ID. If we could keep multiple active, then 1 compromised instance id means we only need to regenerate that one and it wouldn't affect other services.
Intended users
User experience goal
The user should need to deactivate and confirm deletion of a Feature Flag ID, so that human error - would not cause regeneration of the ID to affected services
Proposal
In order to delete an ID - a user must first deactivate it. Once it is deactivated, clicking on the "X" again shall delete it (after a confirmation message)
Further details
Some other added benefits that we would immediately see are:
- Isolated instance ids between environments
- Isolated instance ids between multiple clients (we do this)
- Decreased blast radius of an exposed instance id
This can help reduce feature flag downtime which is what this issue causes, it could move toward supporting multiple instance ids, and also to a staged deprecation of instance id removals.