Improve thread safety of ENV on UNIX

[ysbaddaden]

The environ libc pointer is thread unsafe. The getenv, setenv and unsetenv libc calls are also thread unsafe. At best they libc implementations will leak memory and at worst will segfault on a mere getenv call.

I propose to parse environ once at program startup into an internal hash. This happens before we start threads that may mutate environ in parallel and is safe; then environ is never accessed again (and getenv never called). See comments for details.

I added a readers-writer lock to protect the internal hash and libc function calls. Any calls to read and mutate the environment should be safe...

...but it's still thread unsafe in practice because crystal code might get the writer lock and call setenv while another thread executes an external lib function (including libc calls made by crystal stdlib) that internally calls getenv 💣

For this reason, the documentation has been updated to insist that ENV should be considered an immutable global collection.

[ysbaddaden]

CI is broken 😞

In fact Crystal::System::Env is completely broken... despite passing the specs.

Environ is parsed, @@env is populated, and we can iterate the key/value pairs, but trying to find by key fails. It's as if the key/value pair never existed in the first place.

Why? Because we require env before we require hash that will in turn require crystal/hasher and initialize the hasher seed... after we already initialized a Hash (oops).

Maybe I'll use an Array({String, String}) instead of a Hash(String, String).

[ysbaddaden]

I modified Crystal::System::Env to use an array, but I decided to remove the initial parsing of environ. It is not required to fix thread safety issues, especially since we keep mutating the libc environment and libc and libraries will keep calling getenv anyway.

We'll only need the internal collection if we decide to have -Denv=safe. See #16449.

[ysbaddaden]

This is expensive and since we can't return environ anymore, this happens all the time.

I have a simple patch that yields slices to the kv pointer instead of strings, which avoids the intermediary string allocations and directly builds the "key=value" string. I'll push it in a follow up.

[ysbaddaden]

Superseded by #16591 and #16592.