Bug RCA

The test flakiness where the twin/name fragment was becoming null after the same was updated with a new value because of a faulty logic in how twin updates are handled. When a given twin fragment is updated with a new value, instead of overwriting the existing value with the new one, the current code was trying to clear the old value with a null message first, followed by publishing the updated value. This is the cause of the race, as sometimes, the twin query in the test was happening immediately after the null value is processed which results in empty response.

Proposed changes

When existing twin data like {"a": 1, "b": 2, "c": 3} is updated with {"b": 2, "c": 4, "d": 5}, the update is handled as follows:

1. The removed key: "a" is cleared
2. The unchanged key: "b" is not republished
3. The updated key: "c" is republished with the new value 4
4. The new key: "d" is published as new

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

#3559

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s. You can activate automatic signing by running just prepare-dev once)
• I ran just format as mentioned in CODING_GUIDELINES
• I used just check as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments