This reworks the way that the default behavior is selected, in line
with comments. The changes to the enum are reverted, and the
three places which create a workflow definition are now altered to
explicitly choose WorkflowBurst
This includes a change to the TS enum definition - update to match
its C# counterpart.
This also includes a change to the workflow used in the test-case.
There are quite complex reasons for this, as explained here:
https://github.com/elsa-workflows/elsa-core/issues/728#issuecomment-794319236
The real crux of it is that the workflow must have an activity
which suspends it, and that activity that suspends the workflow
must not be the starting activity. This is why I added an unused
set-variable activity as the starter.
This commit shows that the various persistence test cases _mostly_
work OK, with the one exception of ActivityExecuted.
This test case shows that in-memory persistence is
also affected. It seems that that would mean that this
issue is not related to only a single persistence provider.
In fact, in retrospect this is not really a persistence
problem at all, but a problem with the test case. More
information is available in the comments to #728.
This brings some of the tests I was writing for #552 into
this branch. That's where I first repro'd this problem and
I will begin my work based on that.
Actually, this unit test does not repro the issue.
Frustratingly I can't get it to save the executed workflow
into MongoDB at all. I see workflow execution logs
being saved, but the instance doesn't go in.
I'm not sure if this is a mistake I'm making or whether
I have found a different bug of some sort.
This refactor of integration test logic is to boost its
reusability. Moving some functionality to attributes &
customization classes means I can reuse elsewhere without
duplication.
