Skip cache logic when mode is no-store

[frandiox]

We were still running all the cache logic when mode is no-store. This PR changes it to skip the whole cache logic when this mode is specified.

This change means we are not reading from cache anymore in this mode. Technically, the "no-store" only signals "don't write", not necessarily "don't read and return an existing cached response". But I think this might be OK?
Or should we keep reading (checking for existing responses) and only skip writing? That would only be useful when the mode changes across requests depending on some condition... not sure if this would ever be desired.

Checklist

• I've read the Contributing Guidelines
• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've added a changeset if this PR contains user-facing or noteworthy changes
• I've added tests to cover my changes
• I've added or updated the documentation

[blittle]

Would it be bad to also skip reading the cache too?

[juanpprieto]

That would only be useful when the mode changes across requests depending on some condition... not sure if this would ever be desired.

I can imagine this being a desired use case when working with 3rd party CMS data

[frandiox]

Would it be bad to also skip reading the cache too?

This PR skips reading for CacheNone. Trying to find a use case where this is not desirable.

I can imagine this being a desired use case when working with 3rd party CMS data

Hm.. any more specific example that use the same cache-key? I'm having a hard time thinking of a situation where a CacheNone-query should reuse a previously cached response 🤔

[blittle]

I think this is a good chance. Also cache checks are a sub-request from CF's perspective, so essentially every storefront sub-request results in at least two sub-requests. With this change, no cache check means no extra sub-request.

[frandiox]

Merging this for now 👍