Gzip content cache and bugfix cache time calculation

[addreas]

Description

Three things happening here:

• Compressing the content cache to put less pressure on the api-server
• Adding a nil pointer check and fixing logic for contentCacheDuration <= 0
• Remove old spec.json content before setting the status.contentGzip field to further down-size the CR. Not sure if this is a good idea. Might make some users unhappy if things disappear?

Have to create a new content field in the status since changing a type from string to []byte would prevent the operator from reading existing status content which wouldn't be valid base64. Perhaps should remove the old one?

Relevant issues/tickets

#789

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• This change requires a documentation update
• I have added tests that prove my fix is effective or that my feature works
• I have added a test case that will be used to verify my changes
• Verified independently on a cluster by reviewer

Verification steps

[NissesSenap]

In general I think it makes sense that we ignore spec.json if we use something else like gzipJson or url. At the same time it's a breaking change since it will change functionality even though that way of working is probably "wrong".

About "Have to create a new content field in the status since changing a type from string to []byte would prevent the operator from reading existing status content which wouldn't be valid base64. Perhaps should remove the old one?"

Once again this makes a breaking change, at the same time this status filed is new and there are probably not many people that rely on it. So from that point of view I would say it's probably better to remove it to minimize confusion and problem in the future.

I can't remember what we said during the meeting how to handle this PR in general.
Any way I added a few comments.

[addreas]

From what I can tell it shouldn't be a problem to remove the old status.content, as long as the CRDs are updated along side the operator it self. It will be silently ignored when read from the api-server, and not submitted when setting the new values. The api-server doesn't seem to validate existing resources when changing a CRD, only when submitting the actual resource.

I changed the clearing of the old spec.json data to only happen when the freshly downloaded content is identical. Either way this only happens when fetching is going on, and the fetch has been successful. If the fetch fails the fallback behavior is the same as before.

[HubertStefanski]

LGTM!