Remove SetOptions method from builder

[boma96]

Motivation:
We have two different ways of specifying workflow version.

• SetOptions method(with additional metadata)
• VersionAttribute

Main reason VersionAttribute was introduced was to be able to use scaffolded workflows with version greater than 1(i.e. we always assumed workflow had version equal to 1).

Problem with SetOptions:
If the workflow class itself is used directly in another workflow as subworkflow then we do not have ability to read workflow version which was set in SetOptions. In that scenario we had to use VersionAttribute

I have decided to remove SetOptions so scenario above can not happen. Functionality of setting metadata is now achieved using WorkflowMetadataAttribute.

using ConductorSharp.Engine.Builders.Metadata;

namespace ConductorSharp.Engine.Tests.Samples.Workflows;

public class WorkflowMetadataWorkflowInput : WorkflowInput<WorkflowMetadataWorkflowOutput> { }

public class WorkflowMetadataWorkflowOutput : WorkflowOutput { }

[WorkflowMetadata(
    OwnerEmail = "[email protected]",
    Description = "This is description",
    OwnerApp = "Owner",
    FailureWorkflow = typeof(ConditionallySendCustomerNotification)
)]
public class WorkflowMetadataWorkflow(
    WorkflowDefinitionBuilder<WorkflowMetadataWorkflow, WorkflowMetadataWorkflowInput, WorkflowMetadataWorkflowOutput> builder
) : Workflow<WorkflowMetadataWorkflow, WorkflowMetadataWorkflowInput, WorkflowMetadataWorkflowOutput>(builder)
{
    public CustomerGetV1 GetCustomer { get; set; }

    public override void BuildDefinition()
    {
        _builder.AddTask(wf => wf.GetCustomer, wf => new() { CustomerId = 1 });
    }
}

Also, all metadata attribute classes(OriginalName, Version, WorkflowMetadata) are moved into new namespace
ConductorSharp.Engine.Builders.Metadata

[ognjenkatic]

This looks good but i think it might be a bit confusing having three different attributes we use for what is essentially all metadata.

• Version
• Owner etc.
• Original name

Maybe these could all be merged into a single attribute, something like ConductorWorkflow, and to be consistent perhaps have something like ConductorWorker for tasks, maybe these could be used then to find and register these classes automatically for DI. This is only a suggestion however, my thinking is that it would be good to reduce the number of steps in which tasks/workflows are registered/configured to avoid confusion.