Enable tags cache plugin by default for Views

Let's see, this just switches over to tag, but I'm quite convinced that we need some logic to opt out once you have for example an exposed text field.

Yeah indeed I forgot to pull HEAD .

And here now even with a patch

Render cache item not found. Other RenderCacheIntegrationTest.php 50 Drupal\views\Tests\RenderCacheIntegrationTest->testFieldBasedViewCacheTagsWithCachePluginNone()

Its really convincing that we fail here :)

Here's a diff of all the views yml files in core not updated by this patch

And here's the output of checking each of those for a reference to cache:
more ~/patches/views.do-not-test.diff |grep "^+"|cut -d"+" -f2|while read r;do grep -2i cache --color "./$r" && echo $r;done;

        options:
          perm: 'access content'
      cache:
        type: tag
        options: {  }
core/modules/node/config/optional/views.view.frontpage.yml
status: true
dependencies: {  }
id: test_cache
label: ''
module: views
--
--
      defaults:
        filters: false
        cache: false
      cache:
        type: time
        options:
--
--
          output_lifespan: 3600
      filters:
        test_cache_context:
          id: test_cache_context
          table: views_test_data
--
          table: views_test_data
          field: test_cache_context
          relationship: none
--
          relationship: none
    cache_metadata:
      contexts:
--
      contexts:
        - views_test_cache_context
core/modules/views/tests/modules/views_test_config/test_views/views.view.test_cache.yml
  module:
    - node
id: test_tag_cache
label: ''
module: views
--
--
      access:
        type: none
      cache:
        type: tag
      exposed_form:

As seen by that diff, the views yml files in core not updated to have tag as their default fall into two categories:

1. those that don't have a cache: entry (and will receive the new default of tag)
2. those that do, but already specify time or tag

All the others are already updated by this patch

Manual test next, but code review is RTBC in my book

Installed and manually tested a few built in views, looks good to me.

Content admin screen works with exposed filter too

Not convinced by it yet, honestly :)

views.do-not-test.diff no longer applies.

error: tmp/modified.txt: No such file or directory

Opps automated alex mistake...

@dawehner Are you still concerned that there are circumstances where the cache is not invalidated properly?

I also think a contrib module could be written that flags certain query arg contexts (e.g., url.query_args:AN_OPEN_ENDED_TEXT_FILTER) as too open-ended to cache. I don't think core needs to make such optimization opinions though. But, looks to me like HEAD's FilterPluginBase::getCacheContexts() returns just url as the context rather than the specific query arg, so I think that needs to be changed to support such optimization in contrib. Could be a followup though.

I also think a contrib module could be written that flags certain query arg contexts (e.g., url.query_args:AN_OPEN_ENDED_TEXT_FILTER) as too open-ended to cache. I don't think core needs to make such optimization opinions though. But, looks to me like HEAD's FilterPluginBase::getCacheContexts() returns just url as the context rather than the specific query arg, so I think that needs to be changed to support such optimization in contrib. Could be a followup though.

Oh good catch. There used to be a time when we didn't had more specific cache contexts ...

Added a follow up: #2503185: Specify a more specific cache context in FilterPluginBase

Wow, I didn't realize this had already happened! I should go on vacation more often :D