Remove incorrect utf8 conversion of ResultCache keys

[kgyrtkirk]

• remove the incorrect call to read the byte[] as utf8
• not sure about its origin - but this will push the contract for Cache implementations to handle the byte[] in NamedKey - its already a byte[] - so they shouldn't expect any better than that...
• use Cache.NamedKey instead of passing byte[] and creating the key at multiple places
• added some test to ensure that cache implementations are able to accept such keys

Fixes #16552

[clintropolis]

lgtm 👍

[clintropolis]

nit: maybe make a version of NamedKey for result cache where the nsBytes is already computed so we don't have to call StringUtils.toUtf8 on the constant everytime. Also could probably use a smaller string since the segment level cache uses segment identifiers for the namespace, so unlikely to have any collisions.

[kgyrtkirk]

I've changed the resultcache namespace to RES

the toUtf8 stuff is a bit more complicated:

• I wanted to push out the String/byte[] conversion from the NamedKey and change the namespace to use byte[];
  • however: the MapCache directly accesses the namespace field of the NamedKey class
    • since its being used as a key in a Map it must provide a valid equals - this could be addressed with a small refactor around there to use ByteBuffer
  • the namespace also appears as an argument to Cache#close - so this will kinda force that to change as well
    • this could force changes in the segment cache key generation stuff
  • ...so this path leads to refactor(s)
• I could store the byte[] next to the String by passing that as well in the constructor - but I would rather not do that unless there are measurable benefits of doing so
• status quo also have some pros: the toByteArray is not used in all cache implementations - so the toUtf8 might not be even called

I think for now it would be best to just leave this alone; not passing the full cachekey as the namespace have kinda reduced the key sizes to around half

[clintropolis]

cool, re complicated stuff i guess i was imagining just subclassing it or something so parts could be constant, but if its complicated then seems fine to skip