* Publish/Subscribe events added to WorkflowSettings and WorkflowRegistry
* Workflow Registry re-indexed and cache refreshed on workflow disable/enable
* IsDisabled property added to WorkflowBlueprintSummary to display disabled status in the UI
* MySql, PostgreSql and SqlServer persistence added to Workflow Settings
* Validation for disabled workflow in Workflow Resumer
* WorkflowSettings configuration added to the appsettings.json
* Workflow Settings added to Elsa.Server.Host startup collection
* IWorkflowSettingsProvider implemented
* Update README.md
* Elsa-Workflow-Settings and Elsa-Webhooks separate modules added and decoupled from Elsa Web
* Delete unused Client projects
* LoadWorkflowSettingsDisabledHandler changes
* FeatureProvider removed, Webhooks plugin merged to Webhooks Feature Plugin
* Update Webhooks and Settings plugin
Co-authored-by: Sipke Schoorstra <sipkeschoorstra@outlook.com>
fixes an issue where correlated workflows of different definitions could not signal one another if the signal matches a workflow instance but was not listening for that signal. All startable workflows should always be considered except for the workflow definition that has an already correlated workflow instance matching the correlation ID.
When a parent workflow triggers another workflow using signaling and using the same correlation ID, the distributed lock provider would try to acquire a lock on the same resource, causing a deadlock situation.
This isn't the final fix.
Having "pending" outcomes isn't practical - it would require the user to always connect them to the activity itself if they did not want to continue the workflow.
