As well as providing a unit test which matches other persistence
provider tests (round-tripping a workflow instance), two other tests
are included here:
* When using the default DI registration extension method, this sets
up pooling of DB contexts and so a resolved context will come from
the pool.
* When using the non-pooled DI registration extension method, this
sets up EF without pooling, which is more useful in a multi-tenanted
environment.
There are also some other changes in this commit corresponding to
improving the tests. Mainly de-duplicating logic & improving names.
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.
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.
