implement setup and lookup_root, add inode pruning to hybrid ID

[khanhtranngoccva]

This method aims to solve issue #86 by ensuring every inode has at least one chance to have a stable backing ID, as well as making a few major modifications on the hybrid ID to allow for trivial ID creation (to pass into prune(), make it easier to unit test, and separate code concerns).

Here are the changes:

1. Create a setup method that runs pre-mount to allow the implementations to store the TResolver types.
2. Create a lookup_root method that runs pre-mount to allow the implementations to return a proper backing ID for the root inode. Currently, if the method is not implemented (ENOSYS), the bootstrapper that runs the code only warns the user.
3. For the theoretical ease of unit testing, HybridId no longer has the convenience methods. It is instead moved inside the resolver types, which also allows separation of concerns. It also makes sense, because the HybridId's internal inode might become invalid through a forget() call when the struct is still in scope.

I'm also considering that the inode resolver APIs should return an error at inode_mapping level since the user can now pass invalid inodes.

[Alogani]

Hi @khanhtranngoccva

Upon a quick review, nothing i disagree on. I will take a bit more time to merge it because i will merge it with v0.5.0 which will be release in a week or two.

Just for information, i will certainly look into more details into for inode_multi_mapper to understand more how it works and see if some logic can be shared with inode_mapper ; and add more comprehensive examples of usages

[khanhtranngoccva]

I made a few more changes:

1. All specialized methods of HybridId may return a HybridIdNotFound error, which happens if an ID is stale.
2. The resolver structures are made public, allowing the user to use any specialized methods marked with pub.
3. A method which invalidates an inode's path is introduced. In case a path like path/to/A no longer represents inode A, the new method HybridResolver::invalidate_path_of_id may be called with (A, path/to/A). After the call, path/to/A can no longer be retrieved by HybridResolver::all_paths for inode A, but the inode's ref count stays the same. Please let me know if the method needs a better name.
   The expected flow is that when FuseHandler::open() is issued, the implementors loop through paths specified by all_paths() or first_path() depending on accuracy needs. After the opening attempt, if the file is not found (ENOENT) or the backing file ID mismatches with the result retrieved from backing_id(), the path is discarded, and the next path is tried, until the inode runs out of paths.