Problem:
When using taskService.submitStartForm(..) for a process with async start event, the resulting historic form property update entities miss the activity instance id of the start event.

Failing test case:

Explanation:
We have this problem because for form data, we create a special process instance start context, more specific an instance of org.camunda.bpm.engine.impl.persistence.entity.util.FormPropertyStartContext.
This context is called back AFTER the async continuation. At this point, it cannot be reconstructed (and especially the form properties cannot be reconstructed since they are not persisted in the DB).
CAM-2636 tackled this problem and sets the form properties already in the SubmitStartFormCmd and fixes the problem that form properties do not appear in the database at all. However, this has the drawback that in the command, the activity instance id is not known yet and therefore misses in the historic entities.

There is no simple way to solve this problem because the raw form properties should not be persisted in the DB (they must be processed by FormFieldHandlers first), yet the HistoricFormPropertyUpdate entites should contain the raw value. Thus, the update events have to be fired before the async continuation at which point the activity instance id is not known. Shifting the async continuation to later atomic operation such that the process instance start context is invoked synchronously is no solution since this would result for example in listeners being called synchronously which defeats the whole purpose of the async start event (the purpose being that listeners are NOT invoked and therefore processes can be started everywhere).