Bump frontend results cache version

[colega]

What this PR does

Added a cache.Versioned wrapper and used it to bump the frontend's result cache version, which is needed to invalidate results that might have been cached by a previous version of the code.

Which issue(s) this PR fixes or relates to

Fixes #1625

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pstibrany]

LGTM, thanks.

[stevesg]

Neat approach, I like it.

What the thought process for downgrading? Or more commonly, rolling back in a panic scenario. You could argue that there is no need to invalidate when going back a version, but I don't think it is worth spending time on.

[nit] Would it be worth somehow better highlighting cache invalidation in the CHANGELOG? Do we have a convention for putting important notices at the top of the file? It is definitely something an operator will want to be aware of when rolling out the release. I'm imagining the scenario: "queries got slower after I rolled out xyz.."

[colega]

What the thought process for downgrading? Or more commonly, rolling back in a panic scenario. You could argue that there is no need to invalidate when going back a version, but I don't think it is worth spending time on.

Downgrading version doesn't require any extra thoughts, the previous keys might still be there (or maybe not, if they were evicted by memcached's decision) but key space is disjoint so nothing special is required.

Would it be worth somehow better highlighting cache invalidation in the CHANGELOG? Do we have a convention for putting important notices at the top of the file? It is definitely something an operator will want to be aware of when rolling out the release. I'm imagining the scenario: "queries got slower after I rolled out xyz.."

I've added it at [CHANGE] section, I'd expect the operators to check at least that section.