Leader election for pods

**Is your feature request related to a problem? Please describe.**
We are presently unable to run multiple pods due to the potential for duplicate attempts to write the ingresses and other objects. We need a HA solution so that if a pod fails there's a backup that can take on leader roles such as creating ingresses.

**Describe the solution you'd like**
Implement a leader election process using kubernetes leases.
ghostcloud-kube should check for an active lease on startup, create it if it doesn't exist, and if found skip all scheduler activities that involve writing.
Reading activities such as future controller endpoints should remain available.

**Describe alternatives you've considered**
Alternatively, we can perform checks within the scheduler during runs to isolate actions that are in progress or can be taken by any one pod.
Alternatively, we can implement a PostgreSQL database to store the leader election status. (We'll eventually need this but leases are designed for this feature and we're building with Kubernetes as a dependency)

Start by inspecting the operator startup path and scheduler activities that write ingresses and other objects, then review how Kubernetes leases support leader election. Keep reading activities such as future controller endpoints available to followers. Done means one pod holds the lease and performs writes while other pods skip writing and can take over after failure.

Written by the indexing model from the issue text.