BpmnError thrown from an execution listener doesn't cancel activity instance

Environment (Required on creation):

Any Camunda-supported distribution or a JUnit test case.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket):

A BPMNError thrown from an ExecutionListener doesn't cancel the Activity Instance of the corresponding Execution.

Steps to reproduce (Required on creation):

Start a process instance of errorProcess.bpmn on any Camunda-supported distribution or a JUnit test case.

Observed Behavior (Required on creation):

The process instance is marked as completed. However:

• The history view in Cockpit EE shows the Service Task activity instance as running.
• There is no end time set on the Service Task (historic) activity instance.
• The Historic Activity Instance state remains at '0' (running).

Expected behavior (Required on creation):

When a BpmnError is thrown from an ExecutionListener, the corresponding activity instance is marked as "canceled" and an "end time" is set.

Root Cause (Required on prioritization):

• A Historic Activity Instance End Event is never created in the problematic scenario. The following code is never reached: https://github.com/camunda/camunda-bpm-platform/blob/c1caeba20ffd2b2de5034292652479af0cb50b45/engine/src/main/java/org/camunda/bpm/engine/impl/history/producer/DefaultHistoryEventProducer.java#L750
• That is because the history execution listener comes after the user-defined execution listeners (this is fine), so it is not executed anymore in the normal invocation loop when the activity ends, and it is also not invoked on cancellation of the activity instance (because we want to avoid invoking user-defined execution listeners twice)

Solution Ideas (Optional):

• We should then make sure that the activity instance always transitions to the ending state (with its side effects, like creating history events), while still ensuring that no execution listener is executed twice (on end, and then on cancel).
• Maybe it makes sense to couple the transition from one activity state to the next stronger to the effects that must happen with that transition, so that such inconsistencies are less likely to occur in the future. Might be hard to achieve though.

Hints (optional):