[BUG] Existing FastEndpoint configuration doesn't work well with Elsa's WorkflowsApiFeature

[ChocoMelvin]

Bug Report: Conflict with AddFastEndpoints in Elsa's Module Configuration

Description

Elsa's API feature automatically calls AddFastEndpoints within a nested extension method (AddFastEndpointsFromModule), causing conflicts for applications that also use FastEndpoints independently. Since FastEndpoints should be registered only once, the current design leads to bad endpoint configuration issues and prevents developers from having full control over their FastEndpoints setup. Furthermore, UseWorkflowsApi calls app.UseFastEndpoints without limiting this configuration to Elsa's own assemblies. This causes endpoints to be mapped multiple times with different configurations.

Steps to Reproduce

1. Create an application that uses Elsa’s workflow API (Elsa.Workflows.Api) and FastEndpoints.
2. Notice that Elsa’s internal call to AddFastEndpoints occurs within ModuleExtensions.AddFastEndpointsFromModule().
3. Notice that Elsa’s internal call to UseFastEndpoints or within WebApplicationExtensions.UseWorkflowsApi() is not limited to elsa's own endpoints, same goes for MapWorkflowsApi.
4. Attempt to register additional FastEndpoints in Program.cs with a different configuration that conflicts with Elsa (i.e. c.Endpoints.ShortNames = true;) using UseFastEndpoints or MapFastEndpoints after the elsa configuration.
5. Run the application and encounter conflicts due to conflicting endpoint registrations.

Reproduction Rate: Always if using mentioned configuration.

Expected Behavior

1. Leave the configuration of FastEndpoints up to the programmer in the startup.cs
2. Mapping of endpoints is limited to Elsa's own endpoints.

Actual Behavior

1. Elsa takes over FE configuration itself.
2. Mapping endpoints is not limited to Elsa's own endpoints.

Troubleshooting Attempts

The following works for my use case. Note: this is my own specific code, some of this may not be relevant.

1. I have made a copy of the WorkflowsApiFeature excluding the call to add FE.
2. I made a static container gathering all the necessary assemblies.
3. I have added those assemblies to the AddFastEndpoint assemblies configuration.
4. Limited the mapping to Elsa('s own name space).

        endpoints.MapFastEndpoints(config =>
        {
            config.Endpoints.RoutePrefix = "elsa/api";
            config.Endpoints.ShortNames = false;
            config.Endpoints.Configurator = ep => ep.Tags("elsa");
            config.Endpoints.Filter = (ep) => ep.EndpointType.Namespace?.StartsWith("Elsa") == true;
            config.Serializer.RequestDeserializer = ElsaSerializers.DeserializeRequestAsync;
            config.Serializer.ResponseSerializer = ElsaSerializers.SerializeRequestAsync;
        });

6. Added Elsa swagger docs by using the tag I added in the snippet above:

        services.SwaggerDocument(o =>
        {
            // Use elsa tag to filter out endpoints that are not elsa related
            o.EndpointFilter = ep => ep.EndpointTags?.Contains("elsa") == true;
            // Check if has ElsaEndpoint wrapped class
            o.DocumentSettings = s =>
            {
                s.DocumentName = "elsa";
                s.Title = $"ORG (Elsa)";
                s.Version = "v1.0";
            };
        });

Additional Context

I am not sure what the perfect solution would be here.
This convention is used in other places as well (SignalR hub for example).
I get that this is difficult because it's a though line between giving the user too much control and potentially breaking Elsa configuration.