Implement global measures

[Jogius]

Summary

Closes #1350.

This PR aims to implement (global) measures by

1. Adding the datamodels for MeasureProperty, MeasureTemplate and Measure
2. Implementing execution logic for the properties
3. Hardcoding couple of basic measure templates
4. Adding UI for participants to execute measures

Also

• Closes Increase Thickness of Stroke for Draw-Line-Measure #1404
• Related Create Log Entries for Scoutables, Technical Challenges and Measures #1401

PR Checklist

Please make sure to fulfil the following conditions before marking this PR ready for review:

• If this PR adds or changes features or fixes bugs, this has been added to the changelog
• If this PR adds new actions or other ways to alter the state, test scenarios have been added.
• By signing off my commits (git commit -s), I certify that I have read and adhere to the terms of the Developer Certificate of Origin 1.1 and license the code in this Pull Request under this projects license (LICENSE-README.md).
• If I have used third party code that requires attribution, I have mentioned it in the code and updated inspired-by-or-copied-from-list.html.

[fekoch]

I like the way of having the measures in an out-of-view menu. (This delays confronting trainees with all available measures.) Also the placement seems like a good fit.

Some thoughts for now:

• You should extend the expansion button using a descriptive text "Maßnahmen".
• We should try the UI on both a large smart board and a tablet to get a better feel for it.
• Some kind of feedback is needed, that a measure is going to be executed.
• As trainer, I want to see that there are measures available.
• As a trainer, I want to enable or disable this feature in the exercise settings. (EDIT @hansegucker: Already covered by data model.)
• I do not get the purpose of the title text? And I can not think of a future use for it.

A thought for the future:

• For non-parallel exercises with multiple participants, measures could still be useful but maybe need to be enabled/disabled one-by-one on each view port separately.

[hansegucker]

I mostly agree with @fekoch, but additionally I would consider the following things

• I think the buttons for measures that should only contain one area with text in one font size.
• The buttons are little bit flaky (I am not sure why).
• We probably shouldn't use the toasts as indicator for the measure delay.

[Jogius]

@fekoch

Some kind of feedback is needed, that a measure is going to be executed.

I was thinking about this too. I temporarily added a toast when a measure is executed and aborted, but this feels very spammy. I personally think we don't need a generic feedback, because most measures will trigger some behavior -- we could e.g. enforce that a measure always has at least one property which triggers UI, like a manual confirmation, which would make this obsolete.

@hansegucker

We probably shouldn't use the toasts as indicator for the measure delay.

Discussion question: should the user get feedback on the delay / should they know how long they have to wait?

[JohannesPotzi]

mini initial review. More to come.

[fekoch]

(some first things)

[fekoch]

partial review for the shared directory

[fekoch]

Can you make VehicleParameters always immutable instead?

[Jogius]

I did not touch this in this PR. I don't know where this comes from.

[fekoch]

The change is already there on dev-next, just clean it up when merging

[fekoch]

Why do we not have to also do the [Drawing] Add drawing action?
If the frontend independently proposes that, but not the addLogEntry actions, this seems very inconsitent to me

[Jogius]

The problem is that we want the drawings to be displayed before the measure is finally executed -- such that the user who is creating the drawing can see it before confirming/declining if there are more properties after the drawing, and also potential other participants and trainers can see this while it's being done.
While we could implement this for all other measure properties (i.e. creating an EOC log entry) as well, I found that drawings were more of an exception to the rule. Happy to discuss this though.

I had previously implemented for all drawings to be removed again and re-created by the Add Measure reducer, but this did not make any sense since it just added one more action and the state is exactly the same afterwards with both approaches.

[fekoch]

Robert and I talked a bit: One (albeit a bit more involved) way would be, to track draftDrawings as a observable inside the drawing service and, after injecting the service into the drawing feature manager, combine it's observable with the selectVisibleDrawings()-observable from the store.

That way, we could prevent prematurely sending actions about unfinished drawings.

But this could also be treated as future work.

[hansegucker]

Global measures don't work in fullscreen.