Add a very basic NFS server implementation

[qmfrederik]

This PR adds a very basic NFS server implementation to DiscUtils. It's intended as a foundation for anyone who wants to build a NFS server in managed code, not as a product you'd use on its own.

The NFS server implementation is split in two classes:

• Nfs3Server implements the RPC part. It reads calls from the client, parses them and invokes a corresponding method. It then returns the result to the client. If you want to write your own NFS server based on DiscUtils, you'd inherit from this class and override the various methods.
• Nfs3FileServer is a basic implementation of Nfs3Server which uses the file system as a backend. It allows you to expose any directory as a file share. It's POC code and doesn't include any error handling or authentication, though.

There are also unit tests for the server and client implementation. But, rather than communicating over TCP, the IRpcTransport interface is mocked and implemented using a Queue of byte[] objects. That speeds up the unit tests and removes networking from the equation.

[LordMike]

Are we sure this should be part of DiscUtils?

It might be a good candidate for a seperate project though, f.ex. DiscUtils.Servers.NFS (if it's to be part of DU).

[qmfrederik]

Are we sure this should be part of DiscUtils?

I'm not sure, and don't really have a strong opinion on it 😄. NFS and iSCSI are two 'network-based' file systems which are part of DiscUtils and I guess you can argue whether they should be in scope at all.

I'm fine with splitting the server part off to a separate project.
On the other hand, it's just two/three source files, so not sure whether it's really worth the effort.

If we do move to a separate library, some additional classes inside DiscUtils.Nfs would need to be made public.

I'm going to keep pushing to this branch for now as I complete the server work; let's continue the discussion.

[LordMike]

Ok - so the API stuff, like protocol messages and potentially even a client, without a doubt should go into the NFS package. An actual server is another thing entirely .. I would still think it needs to go in another package, like DiscUtils.NFS.Server (and at that point, it should be something you instantiate in a consuming program, with options n stuff).

As for public classes. In some cases they should be public (else others wouldn't be able to make their own NFS servers), while others probably can go by with being shared in an InternalsVisibleTo-style thing.

[qmfrederik]

I did some more work on the NFS server implementation:

• Reworked the code a bit, and moved the NFS server-related code to a separate DiscUtils.Nfs.Server library. That should help keep things separated.
• Updated the NfsFileServer class so that instead of serving from a directory on the local operating system, it can serve files from any class that implements IFileSystem. So if you wanted to, you could now setup a NFS server which serves the contents of a IMG, VHDX or ISO file using DiscUtils.
• Better support for weak cache consistency.

As to testing, I used the NfsServer utility to share a folder on my Windows machine and access it from a Linux VM.

Some of the operations I tested are:

• Mounting the file share
• Listing contents of a folder
• Creating a new file with touch/nano/echo
• Modifying a file
• Renaming a file with mv
• Deleting a file with rm

I tested with both the Facebook nfusr library as well as normal Linux mount. (nfusr has more verbose debug output, doesn't required sudo permissions and is easier to restart).

Long story short, things starting to look good 😄 .

[LordMike]

Great :)

What's lacking?