feat: SG-35309: Set and save OCIO environment variable if missing and config is chosen

[deltag0]

feat: Set and save OCIO environment variable if missing and config is chosen

Summarize your change.

When a user loads a valid OCIO config after opening a file and sets the OCIO as an active display with the environment variable OCIO not set, there used to be an error log. The error log is now gone and the environment variable is set after selecting a config.
Moreover, the config path is saved to user preferences after choosing it.

Describe the reason for the change.

Redundant error logs and console pop ups because once the user loads the OCIO config with no environment variable there's already an error log.

Describe what you have tested and on which operating system.

Tested on Mac CY2025

Add a list of changes, and note any that might need special attention during the review.

N/A

If possible, provide screenshots.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: deltag0 / name: deltag0 (394d400, a6b94fc)

[bernie-laberge]

LGTM

[markreidvfx]

Setting environmental variables at runtime while other thread are running and is not safe. If any thread just so happens to be reading one at the same time as another thread is setting a realloc can happen and getenv will read after free and potential crash. Linux at least performs not shared locking between getenv and setenv as far as I'm aware. I recently fix a bug with some of our RV plugins related exactly to this.

[bernie-laberge]

Setting environmental variables at runtime while other thread are running and is not safe. If any thread just so happens to be reading one at the same time as another thread is setting a realloc can happen and getenv will read after free and potential crash. Linux at least performs not shared locking between getenv and setenv as far as I'm aware. I recently fix a bug with some of our RV plugins related exactly to this.

According to our robot friend, @markreidvfx is right:
Mark is right, and this matters for the PR

The claim is technically correct, well-documented, and has bitten real applications repeatedly:

• environ is a flat char** array maintained by libc. setenv/putenv may realloc it and replace string pointers.
• glibc's setenv takes an internal lock, but getenv does not acquire it — see sourceware #15607 (https://sourceware.org/bugzilla/show_bug.cgi?id=15607). POSIX explicitly only guarantees getenv thread-safety
  in the absence of concurrent modifications.
• The crash mode is exactly what Mark described: a getenv caller dereferences a char* that setenv just freed.
• This isn't theoretical — Rust shipped a CVE around it (CVE-2024-43807 / set_var (https://blog.rust-lang.org/2024/09/19/Rust-1.82-pre-announce-set_var-unsafe.html) marking set_var unsafe in 1.82), Go has the
  same hazard, OpenSSL/curl have warnings about it. It's a known footgun, not an edge case.

I think we should explore an alternative way of setting an OCIO config without having to set the OCIO environment variable.
Thank you @markreidvfx !

[deltag0]

Setting environmental variables at runtime while other thread are running and is not safe. If any thread just so happens to be reading one at the same time as another thread is setting a realloc can happen and getenv will read after free and potential crash. Linux at least performs not shared locking between getenv and setenv as far as I'm aware. I recently fix a bug with some of our RV plugins related exactly to this.

According to our robot friend, @markreidvfx is right: Mark is right, and this matters for the PR

The claim is technically correct, well-documented, and has bitten real applications repeatedly:

• environ is a flat char** array maintained by libc. setenv/putenv may realloc it and replace string pointers.
• glibc's setenv takes an internal lock, but getenv does not acquire it — see sourceware #15607 (https://sourceware.org/bugzilla/show_bug.cgi?id=15607). POSIX explicitly only guarantees getenv thread-safety
  in the absence of concurrent modifications.
• The crash mode is exactly what Mark described: a getenv caller dereferences a char* that setenv just freed.
• This isn't theoretical — Rust shipped a CVE around it (CVE-2024-43807 / set_var (https://blog.rust-lang.org/2024/09/19/Rust-1.82-pre-announce-set_var-unsafe.html) marking set_var unsafe in 1.82), Go has the
  same hazard, OpenSSL/curl have warnings about it. It's a known footgun, not an edge case.

I think we should explore an alternative way of setting an OCIO config without having to set the OCIO environment variable. Thank you @markreidvfx !

Removed setting the environment variable and applied broader fix.