Context:

Currently(/once OPT-3170 is done), when retrieving results of our GroupByParts (e.g. in ProcessGroupByUserTask ), if the result is distributedByNone, the value of each groupByResult is nested in one single distributedByResult. This is then mapped to a ReportMapResultDto, which expects exactly one distributedByResult out of which it extracts the value and adds it to the map with the appropriate groupByKey.

This leads to the following, which is quite unintuitive:

If we need to add empty groupByResults (e.g. for userTasks in ProcessGroupByUserTask that have not been executed yet) and the result is distributedByNone, we create a groupByResult with the appropriate key and a distributedByResult with all null properties. This is then transformed to a `0` value in the ReportMapResultDto.

However, if we have any other distributedBy (not none), the results will not be mapped to a map but to a HyperMap. This means:

1. null keys are not allowed in the distributedByResults
2. we might need more than one distributedByResult (so that all groupByResults have the same distributedByResult keys

For that reason, we currently differentiate between having distributedByNone and distributedBySomething - if it is the first, we add one all null distributedByResult and if it is the latter, we first add an empty List of distributedByResults which is then in a second step filled with the appropriate distributedByResults which have the correct keys but a null value.

This behaviour is a bit unintuitive, if possible it would be good to refactor how we handle the distributedByNone case so that it is more consistent. Alternatively, the behaviour needs at least moved to a more generalised location, so that it is more obvious what's required when adding new distributedBy features to groupBys which so far have no distributedBy options.

Relevant code:
CompositeCommandResult.transformToMap()
ProcessGroupByUserTask.addMissingGroupByBuckets(..)