Issue Description: 

When updating (or deleting) an existing k8s Resource we are receiving intermediate signals to the manager indicating the previous state of the k8s resource. For example, when updating a FAILED Processor the manager receives notification that deployment FAILED to only then receive a READY signal in a subsequent iteration of the Controller loop.

This is caused by our checks for existing resources to not consider the Status on the first iteration of the Controller loop. i.e. a FAILED CRD is first found which leads to a signal to the manager. It is however important to NOT consider the Status on subsequent iterations.

This change would prevent the intermediate Status from leaking from the operator to the manager. 

Acceptance Criteria: 

The intermediate Status update is NOT signalled to the manager for updates (or deletions). HOW it is implemented is up to whoever handles this JIRA. Including the Status check in the first Controller loop iteration is only a proposal.