Adjusting the codebase to the new UI model

[HendrikThePendric]

Without diving into the details too much, because the final UI specs are not completed at the time of writing, there will be two major differences between the LL and EVER in term of user interface:

• In LL the user chooses the outputType ("EVENT" | "ENROLLMENT" | "TRACKED_ENTITY_INSTANCE") first and then the user moves on to select dimensions. In EVER the user selects the dimensions first and then you move on to the select the outputType by clicking one of max three update-buttons (some will be disabled due to impossible combinations)
• In the EVER app a user can select dimensions much more freely than in LL. Since the output type is not selected upfront and we have added better support cross-program selection, the user will be able to select a lot of different types of dimension. Because a dimension can be tied to various programs, stages, and (perhaps) also exist independently in some cases, this can lead to challenging combinations.

The above leads to two kinds of challenges:

• In the code we sometimes refer to outputType to make decisions and this is not going to be possible everywhere. Specifically in parts of the UI that are rendered before the update-button is clicked
• We will have to carefully consider in what context a dimension has been selected and display the dimension chip accordingly. We already do this to some extend, but in the new UI it is expected that this will become even more complex

One part to a solution for both challenges lies in the metadata store I believe: when we add a dimension either due to user interaction with the dimension panel/modal, or from the visualization/analytics response data we need to ensure that we:

1. Ensure we create the correct "nested ID" to guarantee uniqueness
2. Ensure that appropriate context metadata is made available, by either adding relevant properties to a dimension metadata items, by ensuring that all entities that make up the nested ID are added to the metadata store as well

The above will help in many cases in the codebase, where we actually only use outputType because we end up doing a call to getDimensionIdParts, where we effectively try to deal with the fact that when a "nested ID" can be made up out of two parts: firstId.dimensionId. The problem is that firstId sometimes refers to a stage and other times refers to a program. Currently we decide which one it is based on the outputType, but we can do the same by looking up the firstId in the metadata store and using a type-guard to identify its kind.

But there are also parts in the codebase, like here in getChipItemsText where we will simply have to come up with an alternative way to achieve the correct result (in this case decide between rendering i18n.t('All') or ''.

I'll not get more specific right now, but will revisit this issue when the specs are final.