!!! FEATURE: Introduce flushByTags to taggable cache backends

[Sebobo]

What I did

This change introduces the flushByTags method to taggable cache backends. This allows each backend to be further optimised in the future to find the best way to flush multiple tags from its storage.

Resolves: #2717

How I did it

The TaggableBackendInterface and FrontendInterface were extended with the method flushByTags and each provided backend in the core got a simple implementation for it to fulfil the interface.

[Sebobo]

Still have to update the tests

[mficzel]

Fine by reading. Pretty safe aswell as no functionality is changed yet.

[bwaidelich]

+1 by reading, but 3 nitpicks/questions:

1. somewhere @mficzel suggested to introduce the trivial implementation of flushByTags() in the AbstractBackend for a greater backwards compatibility. Was that idea discarded intentionally?
2. I'd suggest not to change the RouterCachingService with this PR (see inline comment)
3. (nitpick): I'd suggest to remove the checklist from the PR description so that it doesn't end up in the merge commit (and thus in the changelog)

[mficzel]

@bwaidelich i scrapped the idea of a trivial flushByTags implementation myself because there is no base class for taggable Backends that could implement this. So this would require quite a bit of restructuring that is not required for this pr.

[kdambekalns]

Two return type errors incoming… 💥

Either make nullable as commented it change the return type description for the methods to no longer suggest NULL can be returned.

[bwaidelich]

i scrapped the idea of a trivial flushByTags implementation myself because there is no base class for taggable Backends that could implement this

I thought something like

class AbstractBackend {
   // ...
    public function flushByTags(array $tags): int
    {
        if (!$this instanceof TaggableBackendInterface) {
           // throw or return 0
        }
        $flushed = 0;
        foreach ($tags as $tag) {
            $flushed += $this->flushByTag($tag);
        }
        return $flushed;
    }

but.. Not sure if the B/C is worth the weird construct in this case

[Sebobo]

i scrapped the idea of a trivial flushByTags implementation myself because there is no base class for taggable Backends that could implement this

I thought something like

class AbstractBackend {
   // ...
    public function flushByTags(array $tags): int
    {
        if (!$this instanceof TaggableBackendInterface) {
           // throw or return 0
        }
        $flushed = 0;
        foreach ($tags as $tag) {
            $flushed += $this->flushByTag($tag);
        }
        return $flushed;
    }

but.. Not sure if the B/C is worth the weird construct in this case

I don't feel good about adding tagging related functionality to the AbstractBackend. I think the handful of custom backend implementations can adjust their code without much effort. We anyway have a super simple "sample implementation" in the existing backends and can add it to the upgrade guide. And packages like Sandstorms optimised Redis backend can already be updated without the need to introduce a major version.

[Sebobo]

Thx everyone!