Duo Workflow parallelize startup HTTP calls inside Duo Workflow Service

Problem to solve

See gitlab-org/gitlab#546189 (comment 2537565264)

I think I see where the startup delay is in Duo Workflow Service. From what I can see we may at least 3 HTTP requests to GitLab on startup. Here is what I'd recommend:

1. Combine or parallelize startup HTTP requests for Duo Workflow Service. When we start a workflow we are at least loading (1) the project, (2) the workflow, (3) the checkpoints. At a minimum it should be straightforward to make some of these HTTP requests in parallel. Instead of using await fetch_blah we can do all the fetch requests and then await them all at the end of the method. We could go further and make a dedicated API in GitLab for returning all the data needed when a workflow starts up and do this all in 1 HTTP request.

Proposal

There are at least 2 possible options:

1. Make a new API in GitLab that returns all the data that we need for agentic chat on startup (including project data and checkpoints). This will allow us to get down to 1 request. It could come from the initial request to load the workflow with an additional parameter like include_context_details=true. That parameter could then merge in all the context that Duo Workflow Service might want.
2. Parallelize the requests by making use of asyncio.gather instead of await. At present we call await for each HTTP request and block the progression on each one in series. Using gather would allow us to have them all run concurrently. This might require some more re-rachitecture to the get all the HTTP requests in 1 place.

Further details

Links / references