Change server.daylight_active to an atomic variable

[enjoy-binbin]

We are updating this variable in the main thread, and the
child threads can printing the logs at the same time. This
generating a warning in SANITIZER=thread:

WARNING: ThreadSanitizer: data race (pid=74208)
  Read of size 4 at 0x000102875c10 by thread T3:
    #0 serverLogRaw <null>:52173615 (valkey-server:x86_64+0x10003c556)
    #1 _serverLog <null>:52173615 (valkey-server:x86_64+0x10003ca89)
    #2 bioProcessBackgroundJobs <null>:52173615 (valkey-server:x86_64+0x1001402c9)

  Previous write of size 4 at 0x000102875c10 by main thread (mutexes: write M0):
    #0 afterSleep <null>:52173615 (valkey-server:x86_64+0x10004989b)
    #1 aeProcessEvents <null>:52173615 (valkey-server:x86_64+0x100031e52)
    #2 main <null>:52173615 (valkey-server:x86_64+0x100064a3c)
    #3 start <null>:52173615 (dyld:x86_64+0xfffffffffff5c365)
    #4 start <null>:52173615 (dyld:x86_64+0xfffffffffff5c365)

The refresh of daylight_active is not real time, we update
it in aftersleep, so we don't need a strong synchronization,
so using memory_order_relaxed. But also noted we are doing
load/store operations only for daylight_active, which is an
aligned 32-bit integer, so using memory_order_relaxed will
not provide more consistency than what we have today.

So this is just a cleanup that to clear the warning.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.25%. Comparing base (380f700) to head (14c3e7a).

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable     #876      +/-   ##
============================================
+ Coverage     70.21%   70.25%   +0.04%     
============================================
  Files           112      112              
  Lines         61464    61465       +1     
============================================
+ Hits          43156    43183      +27     
+ Misses        18308    18282      -26     

Files	Coverage Δ
src/server.c	88.53% <100.00%> (-0.03%)	⬇️
src/server.h	100.00% <ø> (ø)

... and 11 files with indirect coverage changes

[PingXie]

We are doing load/store operations only for daylight_active, which is an aligned 32-bit integer. memory_order_relaxed will not provide more consistency than what we have today. I think what you are looking for is atomic_thread_fence such that the print thread can always get the most up-to-date daylight_active. But then since the refresh of daylight_active is already not real time, I am not sure if we need this delicacy about the synchronization. Is this PR for a real world issue you encountered?

[enjoy-binbin]

No, it is not a real world issue i encountered. I am doing some changes around serverLog and find this, this will generating a warning in SANITIZER=thread:

WARNING: ThreadSanitizer: data race (pid=74208)
  Read of size 4 at 0x000102875c10 by thread T3:
    #0 serverLogRaw <null>:52173615 (valkey-server:x86_64+0x10003c556)
    #1 _serverLog <null>:52173615 (valkey-server:x86_64+0x10003ca89)
    #2 bioProcessBackgroundJobs <null>:52173615 (valkey-server:x86_64+0x1001402c9)

  Previous write of size 4 at 0x000102875c10 by main thread (mutexes: write M0):
    #0 afterSleep <null>:52173615 (valkey-server:x86_64+0x10004989b)
    #1 aeProcessEvents <null>:52173615 (valkey-server:x86_64+0x100031e52)
    #2 main <null>:52173615 (valkey-server:x86_64+0x100064a3c)
    #3 start <null>:52173615 (dyld:x86_64+0xfffffffffff5c365)
    #4 start <null>:52173615 (dyld:x86_64+0xfffffffffff5c365)

Yes, you are right about the "not real time" and the "memory_order_relaxed" things. i guess i am just want to fix the warning in here, reduce the warnings in my env. So this is just a cleanup. Sorry for not making it clearly in the top comment, i will update it later

[PingXie]

LGTM. Thanks @enjoy-binbin

[PingXie]

i guess i am just want to fix the warning in here, reduce the warnings in my env. So this is just a cleanup.

That is a good point, Binbin. Thanks for raising the quality bar, consistently :-)