Conditional inputs

[LukasBenner]

This pull request introduces new functionality to support conditional inputs in the Elsa workflows. The changes include adding new attributes and models to handle conditional inputs and state dropdowns, and updating existing descriptors to incorporate these new features.

This PR is a refined version of PR #5343 for the issue .
The corresponding PR in elsa-studio is

New Attributes and Models:

• src/modules/Elsa.Workflows.Core/Attributes/Conditional/ConditionalInputAttribute.cs: Introduced the ConditionalInput attribute to specify inputs that should only be shown for certain states.
• src/modules/Elsa.Workflows.Core/Attributes/Conditional/StateDropdownInput.cs: Added the StateDropdownInput attribute to specify dropdown inputs with state options.
• src/modules/Elsa.Workflows.Core/Attributes/Conditional/ConditionalInputOptions.cs: Defined constants for different conditional input options.

Updated Descriptors:

• src/clients/Elsa.Api.Client/Resources/ActivityDescriptors/Models/ConditionalDescriptor.cs: Created a new ConditionalDescriptor model to describe conditional inputs.
• src/modules/Elsa.Workflows.Core/Models/ConditionalDescriptor.cs: Added a similar ConditionalDescriptor model within the workflows core module.

Integration with Existing Code:

• src/modules/Elsa.Workflows.Core/Services/ActivityDescriber.cs: Updated the DescribeInputPropertyAsync method to include logic for handling conditional and state dropdown inputs.
• src/modules/Elsa.Workflows.Core/Attributes/InputAttribute.cs: Added properties to the InputAttribute class to support conditional inputs and state dropdowns.

These changes enhance the Elsa workflows by allowing more dynamic and state-dependent input configurations.

A example usage of the conditional inputs could look like this:

using Elsa.Extensions;
using Elsa.Workflows;
using Elsa.Workflows.Attributes.Conditional;
using Elsa.Workflows.Models;

namespace Elsa.Server.Web;

public class CondActivity : CodeActivity
{

    [StateDropdownInput(
        ["double", "string"],
        DefaultValue = "double")]
    public Input<string> ApiName{ get; set; } = default;
    
    [ConditionalInput(["double"], Description = "Double")]
    public Input<double> DoubleInput {get; set;} = default;

    [ConditionalInput(["string"], Description = "String")]
    public Input<string> StringInput {get; set;} = default;

    protected override void Execute(ActivityExecutionContext context)
    {
        object? value = null;
        if (ApiName.Get(context) == "double")
            value = DoubleInput.Get(context);
        else if (ApiName.Get(context) == "string")
            value = StringInput.Get(context);
        Console.WriteLine(value);
    }
}

---

This change is 

[LukasBenner]

@dotnet-policy-service agree company="Mitutoyo CTL Germany GmbH"

[bobhauser]

I'm not sure if your use case is similar to the one we had or not... Our use case is that we have a RunScript task that offers a list of separately controlled scripts that can be selected to be run. Each script has a a different set of parameters which could be configured. The solution we came up with was to support maps of script parameter and Input. So for one script you could have a "param1" parameter that is an Input<string>, and a "param2" that is an Input<bool> - and a different script could have completely different arguments. This is the PR that implements this: #5429. We don't use Elsa Studio, so there is certainly a gap there.

Your case could be completely different, and if it is, please just ignore this comment.

[LukasBenner]

Thanks for your comment @bobhauser.
I think there are indeed some similarities between these PRs.
But I think the usecases aren't exactly the same.
The idea behind this PR is to show inputs in the UI based on the state of the activity which can be altered by e.g. a StateDropdownInput.