Cleanup

[kderme]

This pr adds a new cleanup function field in StateMachine. In the sequential case the cleanup is applied to the final model. In the parallel case, a possible model is created from the existing history. So, even if there is some error or an async exception, or we run each program many times using runParallelCommandsNTimes, the cleanup will be made after each execution. For this reason we have replaced MonadThrow constraints with MonadMask.

This pr adds also a new example test, called Cleanup, with many new properties and metaproperties. The test itself is pretty simple. The recourses are files (not open file handles), created and the cleanup tries to delete all files, by looking the References in the final Model. By the end of execution we test if the test folder is indeed empty an this is our property. We test different scenarios like

• Inject exceptions in semantics, to see if cleanup happens succesfully
• We inject error in semantics, in a command which creates a recourse and after it has been created. In this case it is the user's responsibility to do the cleaup of the Command.
• Test in which cases the cleanup has to be a no-op. In our tests it seems that for the parallel case it is possible that cleanup is called more than once for some recourse, so it has to be a no-op.
• We have metaproperties which test the function which creates the Model from the History. In the sequential case, this is deterministic, but in the Parallel case it is not. We compare the Model created by two different executions and we see that they are not strictly equal.

This pr introduces a breaking api change. Users can add the noCleanup function at the new field of StateMachine to have it work as before.

[kderme]

Tests probably fail because Tasty runs them in parallel, so they affect each other. I had the same issue locally, so I ran them with stack test --ta="-p Cleanup --num-threads 1" Not sure what we can do here..

[stevana]

Perhaps you can introduce more randomness when generating filepaths for Create? Now several tests will have file1 etc in common, but if you generate file-$32_RANDOM_ASCII_CHARS-1 they should almost never clash.

[kderme]

I added some randomness on the testing-folder, wo that different tests don't collide. Maybe I overdid it with the number of new tests, I seems to take again a lot of time for ci to finish, probably I should reduce them.

[kderme]

I think actually the ci timeouts is because lts11 doesn't find the cache and downloads everything. Actual test time seems to be the same as before.