Fix ResolvedKeySpacePath.equals and hashCode

[ScottDugas]

This fixes ResolvedKeySpace.equals and hashCode so that they follow the spec and are consistent.
Notably there were a few issues:

• They did not correctly handle KeyType.BYTES
• They disagreed about what data to use (hashCode used to look at the PathValue, while equals looked at the value)
• PathValue did not implement equals/hashCode
• The remainder was not included.
• KeySpacePathImpl redundantly checked the value from the directory
• It did not check the parent of the ResolvedKeySpacePath.

Fixes: #3594

[ohadzeliger]

As a defensive coding we can add equals and hashCode to AnyValue, though all reasonable implementations should use the static constant...

[ScottDugas]

Maybe, but AnyValue is a private-nested class, so KeySpaceDirectory is the only way to construct one, so you really shouldn't be accessing it other than via the constant.

[ohadzeliger]

This would be the same as getDirectory().getValue(), right?

[ScottDugas]

Only if the directory is a constant. If the getDirectory().getValue() is ANY_VALUE, this would be any value of that type.

[ohadzeliger]

In that case there may be a discrepancy where equals (line 281) compares:

• keyspacePath.value
• KeyPathDirectory.equalsIgnoringHierarchy ->
  • name
  • KeyType
  • directory.value

Whereas hashCode compares:

• name
• keyType
• keyspacePath.value

So it looks as if the hashCode could benefit from the extra hash for directory.value

[ScottDugas]

Ah, yes, that is probably true.
It's not catastrophic to have hashCode compare less than equals, especially given that in standard use cases, if everything else is equal, the directory value should be too.
That being said, it would probably be confusing to anyone else coming upon this, so at least it should have a comment.