Fix Incorrect Variable Change Queue Processing

[APickledWalrus]

Problem

When variables are being changed across multiple threads, a lock is used to prevent concurrent modification. If a thread is unable to acquire the lock, it instead pushes its changes to a queue to avoid blocking the thread. This queue is processed the next time a thread is able to acquire the lock and make changes.
However, the process in which changes are applied has a dangerous flaw. Changes are supposed to be processed oldest to newest so that older changes do not override newer ones. The queue itself process changes in order, but the specific variable update that triggered the queue processing is processed before. This is a major mistake that can lead to the specific variable update being overridden.
This issue was discovered after a report on Discord of seemingly improper variable behavior. The user had some sort of async processes that were leading to the change queue being used. Consider the following scenario:

set {my_var::*} to 10 and 20

Variable's change implementation for SET takes the following action:

1. It deletes {my_var::*}
2. It sets {my_var::*} to 10 and 20

The problem with the current implementation is that it's possible for action 1 to be delayed (pushed to the change queue) while for action 2 a lock is able to be acquired. This results in action 2 occurring and then action 1 occurring, leading to the variable being deleted instead of set.

Solution

The logic has been updated so that the change queue is processed (if changes are available) before the specific variable change.

Testing Completed

I had the user that reported this issue test the patch. They confirmed the issue was resolved.

Supporting Information

---

Completes: none
Related: Reported on Discord