Discourage usage of cache_page decorator with UpdateCacheMiddleware (or make middleware ignore decorated views)

[Serhiy]

If django.middleware.cache.UpdateCacheMiddleware is active and some view is decorated with the cache_page that overrides cache alias, this view will be cached in both caches, first time by cache_page and then by the middleware. Well, at least it will try. And fail if the default cache is memcached and the view response is bigger than its' maximum entry size. While filebased cache will work and even create the cache entry. This way first user to visit when there are no entry in cache will get error instead of data.
So, I guess there should be some warning about this in the docs.
Ideally, middleware should ignore views with overridden cache alias, maybe by means of checking headers like in case of the cache_control decorator.

[Carl Meyer]

Any attempt to fix this should also take into account #15855 -- the cache_page decorator is already basically broken in terms of Vary headers. It shouldn't cache at all, it should mark the response for later caching by the middleware, or something.

[Sarah Boyce]

Although I am now happy with the patch, this might rely on #15855 to be fixed and so further investigation is required in that ticket before proceeding further here

[Wassef Ben Ahmed]

@sarahboyce, update is that I backed out from pushing what's mentioned above.

I guess ticket-15855 will have to be worked on in a separate PR.

for now, I updated the release notes for the approved change.
and, Yes I confirm, UpdateCacheMiddleware still needs to be at the top for it to handle undecorated views etc.

[Sarah Boyce]

Added minor comments on the PR
Before this can be marked as "Patch needs improvement" False, we need to check that this change doesn't introduce issues due to #15855

[Wassef Ben Ahmed]

Its not necessary to have UpdateCacheMiddleware on top, it's only a workaround suggested by ticket-15855, but let's question it?
as without FetchFromCacheMiddleware, the UpdateCacheMiddleware will be just setting the value to some cache with the correct headers but not actually serving them as the value by this decorator will be the one served... so the workaround just causes this problem and fixes nothing.

with this PR, will avoid that unnecessary extra write in the middleware, and continue having “Vary headers“ missing.

on the other hand I think the "vary header" problem is smaller to have compared to doubling cache size so we should proceed with this until someone gathers the courage to deprecate the decorator?