Ensure hash checking a file is a purely read-only operation

[alanmcgovern]

The original implementation had some conveniences which are not great in certain circumstances. The DiskManager implementation would do it's utmost to ensure files were always the correct size/length, and that zero length files always existed on disk.

This is fine except if someone wishes to check if a particular file matches a particular hash - in this scenario, while they simply wanted to see if there was a match, the act of running the hashcheck would also truncate the file if it were too large.

Now the engine doesn't do this, and TorrentManager.HashCheckAsync neither truncates, nor creates zero length files.

If someone takes the step of actually calling TorrentManager.StartAsync, this is a clear sign they really do want to download the torrent, and at that point zero length files will be created, and existing files will be truncated if they are too large. This operation occurs only during the 'Starting' phase, prior to enter 'Downloading' or 'Seeding'. This makes things a little easier to reason about :)

However, to support this in the optimal way additional methods need to be added to some of the interfaces used for IO, such as a get/set length method.

[ManlyMarco]

This is great, it should fix all of my issues. The only thing that would make it better is letting HashCheckAsync use fast resume data.

If you load fast resume data then the "NeedsHashCheck" Boolean is set to false. When you call StartAsync no additional hash check will be performed.

If you don't load fast resume, the library calls HashCheckAsync implicitly when "StartAsync" is invoked to perform a hashcheck.

From an external user perspective - don't call HashCheckAsync unless you want a full file-validating hashcheck to be performed. Either rely on implicit or explicit save/restore of fastresume data or let "StartAsync" do what it needs to do :)