Fix search cache

[ottusp]

Context

Cache policy does not take into account parameters in the request body. It should not, as this is an anti-pattern. However, search requests use a proxy to list method, which, contrary to search, supports cache.

The issue

The problem is that the proxified request still use the arguments passed in the body, just like search request received it. And as cache does not look at body arguments, a search request that looked like this:

// example.com?potato=true
{
    "id": [10, 11, 12]
}

Will have a cache hit with the following request (which is completely different from the previous):

// example.com?potato=true
{
    "title": "Despicable me"
    "related_titles": ["A quiet place"]
}

Solution

The solution has two layers:

1. Add bypass cache to subsequent cached methods in a View call stack. Only the view entry point (i.e. the method that maps to the endpoint hit by the client) will be able to both consume from cache and set values to it. The subsequent method calls ignore caching.
2. Create a new cache key_func for search requests. This key_func takes into account the body passed to the request, so calls for the same url, but with different bodies will now map to different keys, avoiding unexpected cache hits.

[joaodaher]

Although the strategy to prevent double-caching works, creating s new custom directive can become complex because you'll have one more moving part to handle from the client-side POV.
Also, I think problem lies deeper in the architecture: re-usage of list. So we should tackle it directly.

I can see 2 options:

(A) list-no-cache
A new list method with no cache (eg. def _list_no_cache) will be reused by the cached list (def list) and the search (def search) and each one of them have their own dedicated cache.

(B) don't reuse list
Simply don't reuse list at all. Copy its logic to the search.
At first glance it might seem against DRY, but search might have it's own custom logic that differs from the default list, which is actually good.
The code itself is quite simple.

[joaodaher]

You can remove this too from the previous approach.