If context is enabled/disabled and queried concurrently then this results in a
data race/TSAN failure with RunSafely (where boolean variable was not locked).
There doesn't seem to be a reasonable way to enable threads to enable and disable recovery in parallel (without also keeping gCrashRecoveryEnabled's lock held during Fn execution which seems undesirable). This makes enable checking if enabled thread local and seems to be consistent with other thread local usage of crash context here.
clang-tidy: error: copying variable of type 'std::atomic<int>' invokes deleted constructor [clang-diagnostic-error]
not useful
clang-tidy: warning: invalid case style for variable 'gCrashRecoveryEnabled' [readability-identifier-naming]
not useful