Deobfuscate content cache tags to ease debugging

[mhsdesign]

The content cache is currently not easy to debug as we sha1 the workspace (previously content stream id) and content repository id:

current__: DescendantOf_7505d64a54e061b7acd54ccd58b49dc43500b635_test-document-with-contents--main
proposed: DescendantOf_user-editor_default_test-document-with-contents--main

current__: Node_bab3e837199ba538fd8e3e2cc73c4b00fb1a4a97_test-document-with-contents--main
proposed: Node_user-editor_default_test-document-with-contents--main

Instead we should just not do it *g

As delimiters we are restricted by the FrontendInterface::PATTERN_TAG pattern: /^[a-zA-Z0-9_%\-&]{1,250}$/

Related discussion about node aggregate id constraints: #5111
Related discussion about workspace name constraints: #5125

The idea regarding using sha1 or not and the choice of the delimiter was initially started here.

And further continued:

The sha1 is to reduce/fix the length of the key

It was used to avoid special characters to render the tags inconsistent - but this should no longer be an issue with our restrictive ValueObjects.
Re length:
The max length of a cache tag is 250 characters.
SHA1 hashes are 40 characters long.
workspaceName can be up to 200 characters
cr id only 16 (i.e. hashing the cr ID increases its length)

We could just hash the complete tag, but that would obviously make it impossible to read so I would not suggest to do so.
Instead I'd say (sorry, this is not related to your change, but since we talk about it):

• Reduce the length of WorkspaceName dramatically – 200 characters is crazy
• use a delimiter that can' be part of aggregate id, workspace name or cr id
• don't hash the parts at all

[kitsunet]

IMHO a cache tag is WAY too long right now, I would curb that down to IDK, 50chars or so.
I think we can only afford to have our tags unhashed if we can be really really 100% sure it will never contain any disallowed char nor break the length limit, and even then we got to remember this whenever we change any of the component parts at a later time. Dangerous-ish?!