Trigger ReservationStartedEvent / -EndedEvent without user interaction

[danbim]

Currently, the reservation outputs are only persisted if a user opens a reservation manually. As there is no interaction from RS to iWSN the testbed can not know of new reservations immediately.

Creating a "push"-style interaction to inform iWSN of new / deleted / updated reservations would result in a cyclic dependency between RS and iWSN. Therefore, this option is not feasible.

As typically all TR installations have SNAA, RS and iWSN running on the same host nowadays it is definitely an option to integrate RS and iWSN tighter. This would mean that RS could "emit" events onto the PortalEventBus, providing state updates to all interested components immediately. This way there wouldn't be a cyclic dependency but iWSN could start / stop / modify all internal state according to changes in RS immediately. This tight integration would however result in making the distributed execution of SNAA, RS and iWSN impossible as the PortalEventBus is not distributed currently. If needed this (practically unproblematic) limitation could however be overcome by distributing the PortalEventBus later on, e.g., by using a PubSub system. However, this option should be carefully evaluated as to not build in evil performance drawbacks.

For now, the tight integration seems like a reasonable way to move forward.

[danbim]

See also #319

[danbim]

If RS is run as standalone and the RS backend type "REMOTE" is used inside the portal process. As TR does not ship with a standalone version anymore we can remove this type and the "tight" integration (using the EventBusService to avoid cyclic redundancy) is perfectly possible.

[danbim]

If the portal is restarted at runtime we need to replay:

• [x] ReservationStartedEvents, so that all active (ongoing) reservations are initialized
• [x] ReservationMadeEvents, so that the lifecycle scheduling of all future reservations is made