Synchronization fixes.

[devw4r]

Re-add thread synchronization to UpdatePacketFactory and ObjectManager.

This commit re-introduces RLock-based synchronization for the update field mechanism, effectively reverting the removal of locks that occurred in commit #f392c50f

The synchronization is required to prevent race conditions that the Python Global Interpreter Lock (GIL) does not cover:

1. Atomicity of 64-bit updates: These are split into two 32-bit operations. Without locks, a thread generating a packet could capture a corrupted state where only half of a 64-bit value is updated.

2. Consistent Snapshots: When generating update packets, the iteration over bitmasks and field values must be atomic relative to writers to ensure the client receives a consistent "point-in-time" state of the object.

3. Atomic "Check-then-Set": Logical sequences that check if a field should be updated before applying the change are not atomic at the bytecode level and require protection to prevent interleaved updates from different threads (e.g., Network handlers, Player tick, Creature tick or Go's tick).

These changes fix bugs where multiple observers would occasionally see inconsistent state (such as a creature appearing alive for one player and dead for another) due to shared-state mutation or partial updates during packet generation.

• World socket optimizations. (Remove Nagle's algorithm)
• New unified WorldServerTicker for deterministic execution and improved synchronization.
• Fix case were auras like Devotion Aura were wrongfully removed from the player upon killing something.
• Fix case in which players received duplicate update packets upon spawning from teleport.
• Fix issues with ObjectManager value setters and UpdatePacketFactory, which caused some fields to always return should_update as TRUE, spamming clients with updates every tick.
• Fix Resurrection Sickness causing health regeneration to kill the player.
• Make sure unit.die() is called where set_health() calls are made if necessary.