Consider using memmap2 for shm pools

[i509VCB]

At the moment the code inside of src/wayland/shm/pool.rs is a bit of a mess and is effectively a duplicate of the memmap2 crate.

Use of memmap2 would just be internal as we can still get the pointer that was mapped under the hood. Although memmap2 does assume that it can safely deref the mmaped pointer into a slice.

cc @ids1024

[ids1024]

Although memmap2 does assume that it can safely deref the mmaped pointer into a slice.

As long as it doesn't create a slice unless you call deref, that's not a huge problem to use internally. Just make sure not deref it, or expose the type in the public API.

But I'm not sure if memmap2 helps much here. It has a separate backend for Windows, but we don't need that. The most awkward code in src/wayland/shm/pool.rs is the SIGBUS handling, which would still be needed since memmap2 doesn't handle it.

Using mmap directly isn't too bad. And it's a bit more flexible, for instance if something like the MAP_NOSIGBUS proposal was ever accepted into the kernel.