Multiple Get-Update-Loops to update values in RocksDB

[Zelldon]

Description

Related to #12033
Came up in #11813

To update the element instance state (as an example), Zeebe always does first a get, then changes the element instance, and update in RocksDB. This happens during processing multiple times on the same element instance:

https://github.com/camunda/zeebe/blob/28fe054b79fcc7398a086a1576199efef01a122c/engine/src/main/java/io/camunda/zeebe/engine/state/instance/DbElementInstanceState.java#L185-L190

There are many other examples. Also, the same happens whenever a new key is generated.

Potential improvements:

• Once fetched an element instance from RocksDB, keep it in a cache, and apply state changes to the element instance, once the processing completes flush the last element instance state to RocksDB. (At least during debugging, it showed that the number of element instances fetched from RocksDB is mostly limited, i.e., when processing a command it gets the element instance to process and the parent/flow scope element instance.)
• During batch processing, it may happen that an element instance gets created and completed at once (like a start event). In that case, it is not necessary to persist the element instance at all in RocksDB. That way, RocksDB will have fewer tombstones stored moving from memtable to the highest level (and then eventually getting deleted).