Implement seamless upgrade for the community image

[LCaparelli]

Is your feature request related to a problem? Please describe.
In order to provide seamless upgrade capabilities (see #62) we must provide it for the community Nexus use case. This should support both Kubernetes and Openshift, though without using ImageStreams yet.

Describe the solution you'd like
When using the default community image, the Operator is able to automatically:

• determine if a newer micro version of the image is available;
• update to the newer version;
• rollback the update if it fails;
• provide humans with information about attempts (regardless if they are successful or not);

This will probably require a some changes to the Nexus CRD. It should give the user the ability to:

• choose a Nexus minor version [1] (this should not have any effect if Red Hat certified images are in use for now);
• disable automatic updates;

Automatic updates should not be available with custom images as we're unable to determine if they follow semantic versioning.

[1]: I was unable to find information on whether or not the community image follows semantic versioning. Keeping on the same minor is a conservative approach to avoid compatibility issues. If semantic versioning is correctly followed, the user wouldn't need specify any versions as the Operator supports Nexus 3.y.z only.

Describe alternatives you've considered

The CRD fields which could implement this:

• spec.automaticUpdate.enabled: boolean field which lets the Operator know whether or not it should perform automatic updates. Ignored if spec.image is not empty and is different from the default value. Defaults to true.
• spec. automaticUpdate.nexusVersion: this field should contain the Nexus image minor minor version we should stay in. Ignored if spec.automaticUpdate.enabled is set to false or spec.image is not empty and is different from the default value. Must be informed if spec.automaticUpdate.enabled is set to true.

If these fields are valid and the Operator determines an update is necessary it will:

• keep track of the current version in memory;
• change the deployment's image accordingly;
• if the rolling deployment of the new image fails, inform the user via the Nexus CR status and change back to the previously deployed version;
• if the rolling deployment is successful, inform the user via the Nexus CR status;

The operator must be able to check for updates periodically. This can be one by starting a goroutine which checks this from time to time, but updating the deployment is tricky. This goroutine must keep track of all latest minors and expose that with a data structure that optimizes queries (such as map). Once it detects a new version is available, it must update the relevant data structure and initiate reconciliation for all deployed Nexus CRs.

Additional context
N/A

Would you be able to assist in testing this feature if implemented?
Yes.

[ricardozanini]

provide humans with information about attempts (regardless if they are successful or not);

I suggest to use the Kubernetes Events API and also set the Nexus CR a status capable to inform this. I saw that you've already considered this option. 👍

spec.automaticUpdate.enabled: boolean field which lets the Operator know whether or not it should perform automatic updates. Ignored if spec.image is not empty. Defaults to true.

If the image is not empty, but has the same tag as the community one, we should update. We consider a custom image that tag that is not from the official Sonatype Docker registry.

[LCaparelli]

If the image is not empty, but has the same tag as the community one, we should update. We consider a custom image that tag that is not from the official Sonatype Docker registry.

Yup, that makes sense.