Investigate deploying IDM as a deployment in forgeops instead of a statefulset

Currently deploying IDM as a stateful set causes upgrade to incur some downtime. It is desirable though to have no downtime when upgrading the IDM pods in forgeops. See FRAAS-3964.

These are the reasons one would use a stateful set vs a deployment in Kubernetes. See https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#using-statefulsets

Stable, unique network identifiers.
Stable, persistent storage.
Ordered, graceful deployment and scaling.
Ordered, automated rolling updates.

These reasons should not apply to IDM.

1. IDM pods dont talk to eachother
2. IDM doesn't use persistent volumes
3. IDM should not care if idm x comes up before idm y
4. IDM should not care if idm x gets a pod update before idm y

Warren Strange Said at some point using a deployment vs a stateful set was tried and some issues were discovered around the scheduler. IDM should strive for IDM pods to be cattle and not pets, so IDM should investigate deploying itself as a deployment and not a stateful set. See the slack discussion: https://forgerock.slack.com/archives/C9ECR7XED/p1594174858495700.

https://kubernetes.io/docs/concepts/workloads/controllers/deployment

Acceptance Criteria

• File jiras to fix issues blocking deploying IDM as a deployment, or make an official call that IDM MUST be a stateful set.