Describe the bug

In PR #571 , a validation was added to exclude non-child resources, however the validation misses some edge cases.

Expected behavior

getResources() from a container /foo/ should not include /foo/#bar as a child (and anything else that is not a direct child resource).

Actual behavior

It includes /foo/#bar as a child

How to reproduce?

I've tested it with these lines in container.ttl and the unit tests:

# These containment triples should not be included in a getResources response
<>
    ldp:contains <https://example.com/other> , <newContainer/child> , <> , <./>, <child/..>, <#hashtag>, <../> .

The test case failed because the hashtag was not filtered:

[ERROR]   SolidClientTest.testLowLevelSolidContainer » Completion org.opentest4j.AssertionFailedError: expected: <[http://localhost:36023/container/newContainer/, http://localhost:36023/container/test.txt, http:
//localhost:36023/container/test2.txt]> but was: <[http://localhost:36023/container/newContainer/, http://localhost:36023/container/test.txt, http://localhost:36023/container/test2.txt, http://localhost:36023/co
ntainer/#hashtag]>

Output of java -version

No response

Maven version

No response

Additional information

Cause

The problem likely is, that in the verifyContainmentIri method, the normalizedPath.isEmpty() is called as "#hashtag".isEmpty(). In other words, it thinks that the "#hashtag" is a child resource, rather than just a hashtag.

Suggested fix

I'm not aware how to do this in Java, but I'd leave the path parsing to a library that already has all the edge cases built in (hashtag, query params, and not sure if there's more). Similar to how in solid-client-js they use the built-in child.pathname rather than manually parsing the path segments.