fix(engine): Skip ByteArray Deletion when Updating Var

[tasso94]

Problem Description: During Set Variable and Read Variable operations, the following partial ORM operations can occur in a problematic sequence:

• Thread A reads an Object Variable, thus associated with a byte array value
• Thread B reads the same Object Variable and updates its value to the db
• Now Thread A has a leaking byte array reference that is null

Solution: Instead of deleting an updating the byte array value, during the update, the deletion is simply skipped.
The fix was verified with the customer.

The above behaviour introduces leftover byte-array state on type change. Thus, only during a type change, the byte-array is deleted.

Unit-tests: This commit introduces unit tests that verify the correct state of the variables on type change.

Limitations Accepted: The issue could not be reproduced with a unit test. However, this is accepted since the fix follows a common theme for value update across all the project and is not expected to produce a regression. Moreover, the mere reproduction of the problem using private calls doesn't give any extra value.

Co-authored-by: tasso94, petros.savvidis
Related-to: #4324, https://jira.camunda.com/browse/SUPPORT-21494

[psavidis]

✔ The build has already passed with ci:all-db

[psavidis]

@tasso94 i can't assign this PR to your as a reviewer. Not sure why.

[psavidis]

Notes for the Reviewer

• The behaviour to skip deleting the ByteArray introduces the side-effect of having a leftover byte-array state when the type changes e.g from Object to Long
• To mitigate that problem, the test shouldUpdateVariableStateOnVariableTypeChangeObjectToLong was added to verify that the correct state is populated when the variable has type object, but also when the variable changes to long.
  • That test fails on passes on master because on master, each update will always delete the byte-array
  • On SUPPORT-21721, the test fails without the fix on type change.

Note: The other two tests for Double-to-Object, String-to-Object type changes were added despite the fact that they do not fail on both branches. It is still important to add that coverage for other types

[psavidis]

Closing this PR in favor of a new one to fix the issue with of being unable to assign the issue to @tasso94 (the PR creator cannot be the reviewer i guess)