Remove reset method

[Zelldon]

Description

On each process or onError call we will use a new ProcessingResultBuilder which means we no longer need to reset the ResultBuilder.
Remove the reset from the interface and the implementation

Related issues

closes #10047

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 to the last two minor versions. You can trigger a backport by assigning labels (e.g. backport stable/1.3) to the PR, in case that fails you need to create backports manually.

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
• The change has been verified by a QA run
• The impact of the changes is verified by a benchmark

Documentation:

• The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.)
• New content is added to the release announcement
• If the PR changes how BPMN processes are validated (e.g. support new BPMN element) then the Camunda modeling team should be informed to adjust the BPMN linting.

Please refer to our review guidelines.

[github-actions]

Test Results

   853 files  ±    0     853 suites  ±0   1h 39m 33s ⏱️ + 1m 53s
6 665 tests +113  6 655 ✔️ +113  10 💤 ±0  0 ❌ ±0 
6 849 runs  +113  6 839 ✔️ +113  10 💤 ±0  0 ❌ ±0 

Results for commit 6e6523b. ± Comparison against base commit bbd0e5d.

♻️ This comment has been updated with latest results.

[korthout]

Thanks @Zelldon

It's not clear to me how we can make this change now. Perhaps my assumptions are incorrect. Please have a look.

[korthout]

@Zelldon Looks like you merged main into this branch. Please rebase your branch on top of main instead.

[Zelldon]

I dont see why this is an problem. BTW I used the github API.

[korthout]

I dont see why this is an problem

Rebasing to resolve conflicts in the branch makes the branch's history linear while merging with a merge commit leads to a split history. Linear history is easier to read.

I thought that this was described in our CONTRIBUTING.md, but it states something that can't be correct:

If there are merge conflicts the author of the pull request has to manually rebase main into the issue branch

I guess it means to say rebase the branch on top of main 🤷

IMO we should keep the history linear, but I'll leave it up to you.

[korthout]

LGTM 👍

[Zelldon]

bors r+

[zeebe-bors-camunda]

Build succeeded:

• Go linting
• Test summary
• Java checks