Add Module::deserialize_open_file

[adambratschikaye]

Add an API to deserialize a Module from an already opened file. This can be useful in situations where wasmtime is running in a sandboxed environment with limited access to the file system. Then another process can handle opening the files and passing them to wasmtime.

[fitzgen]

LGTM, but I am not sure I understand what you are getting at with regards to windows, so we should resolve that before merging. Thanks!

[alexcrichton]

Not necessarily obvious to find but the failure is a Windows-specific one

[adambratschikaye]

Yeah @alexcrichton is right - it looks like a simple File::open doesn't work for windows because the open options need to be compatible with the options used when creating the mapping. I also had to fix up the new test for this and I added a comment on deserialize_open_file on how the file should be opened for windows.

Also ran the full CI on the branch now, so the previous windows failure should be good.

[fitzgen]

I think there is a writable vs readable swaparoo in the docs. AFAICT, it is readable and executable, not writable and executable, and if that is true then this is good to merge with that doc comment fixed.

If my understanding is off, and we are actually mapping as writable and executable, then I think we want to revisit what we're doing here, since that is a pretty scary widget to expose!

[fitzgen]

Does it need to be writable? Seems like it should be (and maybe actually is?) readable and executable?

[adambratschikaye]

In windows we create the mapping with protection PAGE_EXECUTE_WRITECOPY which only requires the file handle was created with FILE_GENERIC_READ and FILE_GENERIC_EXECUTE access (docs here). It looks like write access would only be required if writes were being persisted to the file, but since we use copy-on-write it's not needed. Maybe I should add a link to these windows docs in comment for further clarity?