Provide option to cancel TestEvents if clientTimeout is reached

[I3urny]

It would be nice if the execution client provided an option to also cancel the TestEvents it scheduled in case of reaching the clientTimeout.

Currently, if the execution client reaches the clientTimeout only the execution client will stop but the TestEvents it scheduled will keep running. This mismatch in states could cause trouble in CI/CD pipelines where you'd expect the TestEvents triggered by the execution client to also stop when reaching the timeout.

As far as I can tell, the Execution API does not yet provide an endpoint to cancel the execution event and therefore also does not cancel the associated TestEvents. The only way to cancel the TestEvents at the moment is to utilize the MonitorService.svc and its respective endpoints /GetTestEvents and /CancelTestEvent.

[I3urny]

It seems that starting with Tosca 16.0 there is indeed a new endpoint in the Execution API that provides this functionality. It is just a matter of implementing this in the execution client.

[I3urny]

Apparently features will not be backported in Tricentis Tosca in order to mitigate the risk of introducing bugs into previous versions. The Cancel endpoint will therefore never be available in Tosca 15.2.

Because the execution client is supposed to support both versions there are a few ways on how to solve this:

1. Only support cancelling Testevents on reaching the clientTimeout in Tosca 16.0 and upwards
2. Cancel TestEvents in Tosca 16.0 via the /Cancel endpoint of the Execution API and cancel TestEvents in previous versions via the /CancelTestEvent endpoint of the MonitorService.svc
3. Cancel TestEvents for all versions via the /CancelTestEvent endpoint of the MonitorService.svc

Generally speaking, utilizing the /CancelTestEvents endpoint of the MonitorService involves a lot more work. The requests needed have a completely different structure compared to the already existing requests in the Tosca Execution Client, due to MonitorService being a SOAP interface rather than a REST interface.
I have already implemented the required functions in my fork but that approach also comes with a caveat: TestEvents can only be identified via the Creator.
This is because there is no way to find out which TestEvents belong to the current ExecutionEvent other than by using the Creator. So essentially for CICD pipelines, the Creator would have to be unique so that the TestEvents triggered by this Tosca Execution Client can be identified.

@AgileAOTeam: Is there a Roadmap for the Tosca Execution Client or do you have any preferences?