Consider supporting macOS App Sandbox

[GregoryConrad]

Right now, we are getting sandbox violations from POSIX semaphores not following the proper naming scheme.

See here:

POSIX semaphores and shared memory names must begin with the application group identifier, followed by a slash (/), followed by a name of your choosing.

Currently they are /MDB.... This issue really sucks because I looked briefly in the LMDB source and did not really see great support for customizing POSIX semaphore prefixes as-is. There is some MUTEXNAME_PREFIX macro, but it really doesn't allow for customization as far as I can tell. This would require submitting an issue to LMDB directly and see what they recommend.

Note: The maximum length of a POSIX semaphore name is only 31 bytes, so if you need to use POSIX semaphores, you should keep your app group names short.

Another yippee.

To learn more about application groups, read The Application Group Container Directory, then read Adding an Application to an Application Group in Entitlement Key Reference.

...And this would require library-users to go through plenty of hoops during compilation and to change entitlements.

[GregoryConrad]

With this issue as-is, I am not going to fix this. Not worth the time and it would be an absolute pain. Even once/if LMDB is patched as necessary, lmdb-rs would need to somehow get the POSIX semaphore prefix, and the only idea I have to do this is through a "magic" file placed somewhere really specific, because we can't specify this file in a dependent package's build script. It'd literally be easier to rewrite LMDB in pure Rust (which I have been really tempted to do recently after all the issues I have had with C interop/its dependencies) or tell library users to just fork lmdb, lmdb-rs, heed, milli, and mimir to specify their application group than to try to make all the changes necessary to support this.

[GregoryConrad]

If anyone stumbles across this issue worried, please do know that iOS/iPadOS should be ok for the App Store. I will support iOS for submission to the App Store in mimir since I need it for my application.

[GregoryConrad]

Web support is only going to be possible through a different backend (something other than LMDB, probably redb), which we could actually just set as the default in macOS, which would in turn give us App Sandbox support back!

See #10. If that gets fixed, it is likely App Sandbox support will come back for macOS, but with the tradeoff that all old data will be unreadable by new versions of mimir which is problematic for app authors.

[GregoryConrad]

Update: unlikely this will be supported as I am probably just going to provide an IndexedDB shim over in heed. If milli ever switches to a different K/V backend, then this issue can be reconsidered.

[GregoryConrad]

This might be possible once we have Native Assets; we can add an environment variable of the application group id to the embedded_milli Cargo.toml and then check for the environment variable in lmdb-sys

https://doc.rust-lang.org/cargo/reference/config.html#env

[GregoryConrad]

I'm going to mess around with a redb backend in heed, which hopefully will be able to support WASI for #10. When that is done, and Native Assets are in Dart, there should hopefully be a build flag of sorts (or maybe just an extra entry in user's pubspec.yaml?) so the Dart build script can enable macOS app sandbox support by in turn just enabling the redb backend in heed at a slight performance penalty.