Updates to entities related to a task fire historic task update events

Environment (Required on creation):

7.18.0-alpha2

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

In 7.18.0-alpha2 when modifiying entities related to a task that do not modify the task entity (e.g., add candidate user), the engine fires a historic task update event.

Additionally, the engine produces a task listener event.

Steps to reproduce (Required on creation):

Run org.camunda.bpm.spring.boot.starter.CamundaEventingIT.shouldEventHistoryTaskAssignmentChanges() or org.camunda.bpm.spring.boot.starter.CamundaEventingIT.shouldEventHistoryTaskMultipleAssignmentChanges().
The test creates and deletes several identity link log events and asserts the order and some properties of the events.
The list also contains a historic task update event for each created/deleted identy link log.

Observed Behavior (Required on creation):

The test fails. The list of inspected events does not only contain historic identity link log events but also historic task update events.

Expected behavior (Required on creation):

The test succeeds without modification. That means no historic task update events are fired for changes to entities related to a task that don't modify the task entity itself.

Root Cause (Required on prioritization):

With CAM-14303, we introduced a date property to the task entity called lastUpdated which is set whenever an update to the task entity or associated entities (like variables, identity links, comments, ...) happens.
This means, that for actions that did not modify the task entity, now the task entity is modified. This is done via the triggerUpdateEvent method which also triggers the merge of the entity into the DB causing a MERGED state.

On command context close the engine checks if the entity is dirty (which is fulfilled by the MERGED state) and fires the historic task update event.

Solution Ideas (Optional):

1. Introduce lastUpdated to the history. This would be relatively easy to add. In that case the historic events would be expected.
2. Prevent the historic task update event for persisted changes. The event is produced on command context close. One possible solution would be to inspect the persistent state and don't fire the event if only lastUpdated was changed.
3. Additionally to 2. also prevent the task listener event triggered within the task event lifecycle if only the lastUpdated property was changed.

Hints (optional):