Remove duplicative caching of views rows

This will break views caching tests.

Also if we go ahead here we can probably deprecate CachePluginBase::getRowCacheTags()

Did some profiling:

Umami front page logged in as user/1

With and without the MR, I warmed the caches, then deleted only the views block render cache entry for the recipe collections view, which uses fields:

DELETE FROM cache_render WHERE cid LIKE 'entity_view:block:umami_views_block__recipe_collections_block%';

Then hit the page again and profiled it. This isolates the page differences to the row caching change as much as possible.

On my local while profiling, the row caching is saving around 30ms out of 60ms from that method (see screenshots), so it's having an effect, but it's not much - e.g. it probably takes as much as that to save the cache items on cache misses.

Background reading:

#1867518: Leverage entityDisplay to provide fast rendering for fields
#2381277: Make Views use render caching and remove Views' own "output caching"
#2450897: Cache Field views row output

What I think happened is that #1867518: Leverage entityDisplay to provide fast rendering for fields mostly fixed the performance issue that #2450897: Cache Field views row output was also solving, but they were also interdependent with each other and we didn't fully re-evaluate the need for the caching issue once the field rendering issue landed.

The issue summary from the original issue still has:

how much extra work on a cold cache (i.e. a view with 50 items per page will be 50 additional cache sets)
- can we use multiple get on the rows to avoid 49 individual cache gets? Are 49 individual cache gets + 1 cache set worse than just doing the rendering?

And we never actually resolved those.

I think we possibly could manage to add in 'render cache multiple get' here now since we added that for placeholders, but that doesn't address the extra overhead on cache misses and the overall cache storage needed for the extra items, so can just as well remove a caching layer.

@smustgrave #cache['keys'] is what determines whether a render array gets cached in its own right in the render cache or not, it's only used internally by the renderer, and in this specific case I'm not sure that render array even shows up somewhere you'd be able to alter it.

Rebased.

Rebased.

Rebased.

I warmed caches on admin/content with Umami, then clicked on the first item in the list, edited and saved it, then checked xhprof for the next admin/content load.

That should be more or less the worst case for this change since all but one row will still be in cache.

main views row rendering comes in at around 360ms, the MR here comes in at around 780ms - so rendering all but one items on admin/content the cache saves about 400ms.

However, on a cold cache (after visiting admin/help first), this is saving over 100,000 function calls and approx 300ms (with xhprof overhead etc.) The difference on my local was 2.27 seconds vs 2.0 seconds for the entire request. Can't look at only row rendering in this case, because the overhead is in the render system itself with render cache gets/sets to have to compare total function calls/time really.

Once we get into 10% of 20% of the rows not being in cache (e.g. if other site editors are adding/editing content on the site in between the page getting viewed), then the extra cache sets for those rows will probably cancel out the cache hits for the rows that haven't changed.

So for me it's a worthwhile trade-off to make the worst case better, keeping the best case unchanged, and then the middle cases will be somewhere between a fair bit worse, neutral, and a bit better (e.g. a handful of rows in cache but most rows not). Apart from the raw performance, we're also able to save space in the cache_render bin.

Another thing here is that a lot of requests to admin/content or admin/people will immediately filter the results - when the results are filtered the likelihood of a cache hit on the rows in the filtered list is very low indeed. So with the cache even if we save time on the first request to admin/content, the second request to admin content with filters can be slower.

Had a quick look at what actually takes the time rendering the views rows, and a lot of it is individually looking up path aliases which would be solved by #3518668: Use Fibers for rendering views rows, and a lot of the other time is in access/permissions checks which should be improved by #3539161: Static cache access policy checking.

Very hard to separate out exactly how much is contributed by these and in turn how much would be saved especially since this and the other views issue conflicts, but definitely identifiable savings to be made without additional persistent caching.

Rebased.