Allow the samples operator to be used to configure its imagestreams with an importPolicy.

1. Proposed title of this feature request

Allow the samples operator to be used to configure its imagestreams with an importPolicy.

2. What is the nature and description of the request?

Currently the samples operator does not allow an imagestream it creates to have an importPolicy set. This capability would allow more complete control of imagestreams from within the operator and allows centralised, automated, operator-driven management of the components.

3. Why does the customer need this? (List the business requirements here)

Reasons for needing this are varied.

Primarily it's within the scope of an operator to automate and manage all aspects of the collateral it is responsible for. The importPolicy parameter is a part of an imagestream and therefor managing its value should be within the capability of an operator used to manage them.

The customer use case associated with this request is as follows:

Context:

Disconnected environment using a Quay enterprise registry to pull images inside checking for upstream updates every 6 hours.

Initial state (first start of the samples operator):

Enterprise registry: image:latest references image sha:1234567890Leaf clusters: image:latest references image sha:1234567890

After the upstream reference updates:

Enterprise registry: image:latest references a new image sha:987654321Leaf clusters: image:latest still references old image sha:1234567890 (ie not being updated)

Quay is configured to prune the images that are not references after one day - giving enough time for the leaf clusters to update their references. 

However, after one day, the imagestream on the leaf clusters fail (imagepullbackoff) as the image on the enterprise registry does not exist anymore. It was updated to a newer version and the older image was pruned after 24h.

Rational for request: 

Being able to set the importpolicy on created imagestreams ensures they are updated as frequently as needed/expected. Being able to do it with the operator ensures we are following best practice for an operator deployed resource. Without being able to set this flag from the operator we have to workaround the issue by using per image stream scheduling which is, effectively, an anti-pattern for the operator method.

The preference is to use the operator method to manage this without workarounds or setting the value on each imagestream individually as it would entail a lot of extra work and creates a larger chance of error.

Additionally, as this is all automated being able to set globally via the operator is helpful for developer pipelines and consistency with gitops processes.

4. List any affected packages or components.

Samples operator