Fetching the fallback ACL should not throw an error when the Container is not Readable

Search terms you've used

fallback ACL, container, error, 404

Describe the bug

When trying to fetch the fallback ACL, when the current user does not have Read access to one of the parent Containers, functions that fetch the ACL will throw an error, whereas if fetching that Container's ACL fails (because the current user does not have Control access), it just sets the fallback ACL to null because it couldn't be fetched.

Instead, not being able to get the location of the fallback ACL should also result in null instead of an error, because it, too, indicates that the fallback ACL is not available.

To Reproduce
Steps to reproduce the behavior:

1. Create a Container.
2. Add an ACL to that Container that gives a given user Read and Control access to its children, but not to the Container itself.
3. Create a Resource inside that Container.
4. When logged in as that user, call getSolidDatasetWithAcl() on that Resource.

CodeSandbox

https://codesandbox.io/s/black-butterfly-cbsh3?fontsize=14&hidenavigation=1&theme=dark

Expected behavior

The fetched Resource should not have a fallback ACL available, but it should not throw an error either.

Log output

See CodeSandbox.

Environment

Only attempted to reproduce in the CodeSandbox.

Additional context

Discovered when investigating this question: https://gitter.im/solid/app-development?at=5f894e52bbffc02b581d264c

Start with getSolidDatasetWithAcl() and reproduce the behavior using the CodeSandbox scenario, where a user can read a Resource but not its parent Container. Trace the fallback ACL lookup and verify that failing to locate it produces a null fallback ACL rather than an error.