Allow cancellation of reservations

[danbim]

Currently, although it is possible to delete reservations (from an API point-of-view) it is not possible to cancel them during the reservation runtime. This should whatsoever be possible in the future.

In order to realize this feature we will have to document the lifecycle model for reservations and corresponding lifecycle events to which the internal components and plugins of TR can subscribe. Consumers of the lifecycle events will probably reside inside the portal server. If RS is run as an external service we would either a) have to watch changes by polling RS, or b) not provide RS as external service anymore but rather always embed it so it can post to the internal event bus.

[cmorty]

Is it really that complicated? What about:

• Delete reservation -> RS: reservation ends "now".
• Get a new reservation during the previously reserved slot
• Use new reservation key -> IWSN: Check validity of key -> Delete old session.

The worst that can happen, is that someone frees a reservation and can still use the system. As soon as some else connects with a new key, though, the old key is invalidated. As there is no accounting IMO this solution is way better then the current one.

[danbim]

Would be a feasible solution. However, I would like to at least evaluate the options of having the backend being fully aware of everything that happens at the RS. This way plugins and future extensions can take advantage of this knowledge. E.g., we've always wanted to create an extension that will record all node outputs at server side and log them to some kind of database to have it ready for later retrieval. If that extension knows when reservations are made, start, end or are being cancelled it can nicely log everything. In the other case (if you rely on the client invalidating the current session) you wouldn't have a "correct" view over what actually happens.

[cmorty]

If you implement your extension as a service and trigger it using the client even that will work, as it gets informed that the session ended once the new key invalidates the old one. Worst case you pull the reservation data from the RS in a certain interval.

[danbim]

Now that fixing #354 introduced the possibility for the reservation system to issue events that can be consumed by the rest of the portal process we can listen on "ReservationDeletedEvent" instances. If such an event refers to a reservation that is still ongoing we can then shut down all reservation resources and close e.g., the reservation event store. In order to not lose documentation on reservation history RS has to be modified to not actually delete entries from the database but to cancel them.

• [ ] mark reservations as deleted instead of deleting them in RS database
• [ ] shut down reservation resources upon reservation deletion

[cmorty]

:)