Opportunistic CoW for platforms that support it

[jaybosamiya-ms]

This PR improves LiteBox performance by shaving off ~65% of our execution time by introducing opportunistic CoW:

 _____
< MOO >
 -----
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

Concretely, this PR introduces a new platform interface to PageManagementProvider called try_allocate_cow_pages. This defaults to UnsupportedByPlatform, but any platform that has the ability to support copy-on-write page allocation can override this method in order to automatically obtain improved performance.

The improved performance itself comes from mmap in the Linux shim, where file-based mapping can be sped up.

This is not a trivial "pass through" since the files inside LiteBox need not correspond to files on the host (so even for Linux-on-Linux, there is work that must be done). This motivates the actual design of try_allocate_cow_pages that I've chosen, which is closer to a memcpy-like interface, rather than anything file-oriented. Platforms that have file-oriented support for it are welcome to keep those platform-specific details to themselves. What this means is that mmap on the shim actually first looks up the file, then it checks to get a backing store memory of it; if one exists, then a CoW is attempted, at which point the platform itself does the lookup of the file (on Linux platform) and decides to make a CoW map of the page.

Currently, the biggest gains for us come from the actual ELF load time, since that is all that I have set up as supporting CoW for now (it was our biggest bottleneck; thus the 65% savings in execution time). However, now that the core framework has been set up by this PR, future PRs should more easily be able to unlock performance wherever CoW might help.

There are some small bits I am not yet fully happy with the PR that I've marked with TODO(jb) etc., for example, it'd be good to store pre-loaded FDs rather than constantly opening/closing them. However, that can/will be handled in a future PR.

[wdcui]

I think @CvvT should review this PR.

[CvvT]

Thanks for the change! I have a few questions.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.