restore: trying out mmap-based file extraction

[zkat]

Fixes: NuGet/Home#9807

Results are promising:

Benchmark results from one of our test benchmark projects (the Orchard example)

Note: I couldn't get the NuGet.Client-based benchmarks to work, but the other two worked fine.

TODO

• (SOLVED) You'll notice a bunch of "file already in use" errors in the test failures in CI. These seem to be spurious/random and I'm not sure exactly what's triggering them but I can probably work around it with a try{} around the mmap code that falls through to a regular write. These are rare enough that it shouldn't affect performance, and if we catch the right exception, won't affect correctness (because the incoming stream won't have been consumed at all).
• Have a conversation about max file size to mmap: I'm not sure how many of these extractions we're doing in parallel, but my assumption is "not many, if any at all", so I'm inclined to just... leave it at the current 10mb setting (files smaller than 10mb will be fully slurped into RAM)
• Should we bother flushing? Basically none of our code flushes streams to disk, and a process crash won't prevent mmapped files from being persisted, so I'm inclined to not take the (relatively small) perf hit, and just go "don't power off your computer :)", which is what we're saying already, anyway, for these extractions.

[zivkan]

I've never used mmap before in .NET, and don't remember reading much about it in the past. How confident are we that this will work for everyone in all scenarios? Should we consider checking an environment variable to allow people to turn it off, considering otherwise the only workaround will be to downgrade to older tooling, which might not be an option for other reasons?

Should we bother flushing? Basically none of our code flushes streams to disk

Dispose implicitly flushes. And therefore it's not a perf hit. In fact, for async code this is a problem because dispose is synchornous, and therefore flushing on dispose can block the thread when the code is otherwise async. Therefore for perf it's important to call FlushAsync in async code before disposing. But I think this is a bigger problem with network streams, rather than disk IO. In any case, the method modified in this PR is not async, so it doesn't really matter.

I don't know if it is true that mmaped files also flush on dispose for mmaped files in .NET. I would guess so, as it would be very confusing for developers like us knowing that one type of stream flushes on dispose but another does not.

a process crash won't prevent mmapped files from being persisted

making mmap more relisient than "normal" streams :)

[zkat]

This is ready for another review! I simplified the whole thing. The only stream type that didn't have .Length was the Stream that comes from the ZipArchiveEntry. I've created a wrapper Stream in that case so I can pass the size in from the entry, and that gets rid of all breaking changes (and all visible changes, for that matter. This is now thoroughly tucked away inside CopyToFile)

[zkat]

@dtivel fixed. I had to change how I'm doing the mmap because of issues I had on Linux, but this version is actually passing tests AND performing well :)