Bump Zeebe to version 8.0.0-rc1

[remcowesterhoud]

Description

The ColumnFamily interface in Zeebe has been modified. Before it only contained a put method. Starting from version 8.0.0-rc1 this has been replaced with update, insert and upsert methods.
The delete method has been replaced with deleteExisting and deleteIfExists.

In our in memory database we implement this interface. When updating to Zeebe 8.0.0-rc1 these changed need to be merged to keep the code from breaking.

In addition to the ColumnFamily changes the zeebe-protocol-jackson changed in the way we need to do the mapping. This minor mapping change has also been fixed in this PR.

Related issues

closes #262

Definition of Done

Not all items need to be done depending on the issue and the pull request.

Code changes:

• The changes are backwards compatibility with previous versions
• If it fixes a bug then PRs are created to backport the fix

Testing:

• There are unit/integration tests that verify all acceptance criterias of the issue
• New tests are written to ensure backwards compatibility with further versions
• The behavior is tested manually

Documentation:

• Javadoc has been written
• The documentation is updated

[github-actions]

Unit Test Results

132 files  132 suites   6m 14s ⏱️
232 tests 232 ✔️ 0 💤 0 ❌
896 runs  896 ✔️ 0 💤 0 ❌

Results for commit f79df18.

♻️ This comment has been updated with latest results.

[pihme]

This is a hard one. The changes look ok. But now the behavior of InMemoryEngine differs from Zeebe. In Zeebe the consistency checks are governed by feature flags. Currently the checks are disabled by default.

The tricky bit is that we don't have any notion of feature flags yet in the InMemoryEngine. And maybe we should not? I am torn on this one, to be honest.

I also wonder whether the foreign key checks are in place because they happen on another level, or whether we have to reimplement those as well.

I see two ways going forward:

• we allow to pass in a configuration object and reimplement the relevant feature flags here
• we purposefully deviate from the behavior of Zeebe, but then I would at least try to mimick the default configuration, which currently is with integrity checks disabled.

There should also be tests in Zeebe for behavior of this class with feature flags enabled vs disabled. Maybe we should copy those as well.

[remcowesterhoud]

After some discussion we have decided to keep the changes as they are at this moment. This means we will check for existing keys where relevant, and we will not check for foreign keys.

The reasoning behind this decision is that the ForeignKeyChecker in Zeebe is not reusable in this project as is. If we would add this consistency check it would involve creating it ourselves. This is doable. However, with creating our own implementation we are already deviating from Zeebe. Doing this will raise the question what the value of this check is. It will differ from the Zeebe implementation and it is not something users of this project will require us to have. Any conflict on our foreign key check will be short-lived as the db will be reset after each test case anyways. Worst-case a test will fail.

For this reason we have decided to deviate from the Zeebe database. We aim to keep the databases as similar as possible, but this is not always a feasible option.

[pihme]

Looks good to me.

two minor suggestions