Unpredictable Behavior when Upperdir is also Mountpoint

There's a use-case where the `upperdir` provided is also the `mountpoint`. In this scenario, the directory is fixed and utilized by a particular application or process, and already contains core files. Using OverlayFS, configuration files can be put in place and applied on top of this directory. However, while I'm not entirely sure if this use-case is entirely supported, it is also not forbidden. I would argue for one or the other, in order to prevent confusing or major errors.

Currently, when the `Upperdir` is also the `mountpoint`, there is quite a bit of unpredictable behavior that happens. Listing the mountpoint gives you different results depending on _what_ is listing the directory (for instance, `/bin/ls` gives a certain list, and other applications give a different listing). Still files that _are_ technically there can still be read and written, even by the applications that can't find them when listing a directory.

I'm fully aware of the _reason_ for this instability, because the same location is technically occupied by two different trees. In the worst case scenario, where the directory tree of the Upperdir and the ephemeral Mountpoint overlap, utilities can often times reference one _and_ the other, causing application errors and even, in the worst case scenarios that I've experienced, system instability and crashing.

Preserved from original post

I would advocate for one of two options:

1) Ideally, an unknown level of effort to fix the stability issues and support the Upperdir and Mountpoint being the same location
2) ~Barring this type of scenario altogether~

~While I would obviously prefer number 1 here, I could certainly see the argument that this type of unpredictable behavior may not be easily wrangled, so I would advocate for number 2. Had I received an error in the outset saying `Cannot mount to upperdir`, `Upperdir cannot be the same as mountpoint`, or something similar, I probably would have gone with a different solution (albeit, far less elegant, like just simply symlinking, rsync, or something else).~

~Additionally, there should also probably some mechanism in place to bar the `mountpoint` from being a `lowerdir`.~

After perusing different places, it seems that while `fuse-overlayfs` may or may not openly support it, I've found a number of different places where the `mountpoint` is set to either a `lowerdir` or the `upperdir`, which may make barring this behavior problematic for those doing this already. This would definitely break backwards compatibility since this is technically working with some degree of stability for others.

It might make sense to dig into this a bit deeper, instead, to figure out how it might be possible to remedy some of the stability issues.

Thoughts?

All in all, thanks for the awesome work that's already been put into this project. It's been fantastic for most all other uses I've had.

Start by reproducing the reported case where upperdir and mountpoint are the same, comparing directory listings from /bin/ls and other applications. Investigate the overlapping upperdir and mountpoint trees and determine whether this configuration can be made deterministic or must be rejected. Done means the behavior is consistently supported or clearly prevented with an appropriate error.

Written by the indexing model from the issue text.