Interactive apps

[sverhoeven]

Adds endpoints for interactive applications (<30s).

Which can be run on a directory of a completed job and are configured in yaml file with JSON schema and Jinja template.

Refs haddocking/haddock3#686

This PR also replaces the dynamic routes for application to static ones in the openapi spec.

[sverhoeven]

Notes for self for current implementation

Pros

• Can use job directory without having to copy stuff around
  Cons:
• Different then rest of bonvinlab apps.
• Trust interactiveapp to not do anything wrong in job directory.

Alternative impl

Each app will have own endpoint, /api/job/{jobid}/interactive/rescor instead of /api/job/{jobid}/interactive/{application}, with input schema exposed to openapi spec.

Pro:

• more api gateway like
  Cons:
• Each interactiveapp will have own openapi endpoint.
  The generated openapi client will be specific to bartender instance.
  To use bartender with haddock3-webapp (which has generated client)
  you already need to configure haddock3 as application in config.yaml
  so this is not a big deal.

[sverhoeven]

Now we have 3 dynamic endpoints:

• GET /api/job/{jobid}/interactive
• GET /api/job/{jobid}/interactive/{application}
• POST /api/job/{jobid}/interactive/{application}

These could be replaced with an endpoint for each interactive app. For example for rescore interactive app it could be:

• POST /api/job/{jobid}/interactive/rescore with config.input schema as request body schema.

By calling below to lifespan

def unroll_interactive_app_routes(app: FastAPI) -> None:
    """Unroll interactive app routes.

    Replaces `/api/job/{jobid}/interactive/{application}` endpoint with
    Loop over config.interactive_applications and add a post route for each

    Args:
        app: FastAPI app
    """
    if app.openapi_schema:
        return app.openapi_schema
    app.openapi()
    interactive_applications = cast(
        InteractiveApplicationConfigurations, app.state.config.interactive_applications
    )
    existing_post_path = app.openapi_schema["paths"]["/api/job/{jobid}/interactive/{application}"][
        "post"
    ]
    for iname, config in interactive_applications.items():
        path = f"/api/job/{{jobid}}/interactive/{iname}"
        post = {
                "tags": ["interactive"],
                "operationId": f"interactive_{iname}",
                "parameters": [
                    {
                        "name": "jobid",
                        "in": "path",
                        "required": True,
                        "schema": {"type": "string"},
                    },
                    {
                        "name": "body",
                        "in": "body",
                        "required": True,
                        "schema": config.input,
                    },
                ],
                "responses": existing_post_path["responses"],
                "security": existing_post_path["security"],
            }
        if config.summary is not None:
            post["summary"] = config.summary
        if config.description is not None:
            post["description"] = config.description
        app.openapi_schema["paths"][path] = {
            "post": post
        }

Pros:

• From consumer perspective it is easier to see which interactive apps is available. You can just look at openapi spec. You dont have to call to 2 get endpoints
• Request body is typed in openapi. So generated clients are also typed.

Cons:

• Each instance of bartender web service has own openapi spec. Any web app using bartender would need to generate a client specific for an instance. Making it harder to deploy in different ways.

[sverhoeven]

When the openapi spec has endpoints named after the interactive applications then it makes sense to do the same for the applications as well.

For example with haddock3 application the current openapi looks like

• GET /api/application -- returns list of configured application names
• GET /api/application/{application} -- for an application returns the config filename that should be submitted and optionally which roles a user should have
• POST /api/application/{application} -- for an application submit an archive file

When each application has endpoint it would look like

• GET /api/application/haddock3 -- for haddock3 application returns the config filename that should be submitted and optionally which roles a user should have
• POST /api/application/haddock3 -- submit a haddock3 archive file

[sverhoeven]

When the openapi spec has endpoints named after the interactive applications then it makes sense to do the same for the applications as well.

For example with haddock3 application the current openapi looks like

• GET /api/application -- returns list of configured application names
• GET /api/application/{application} -- for an application returns the config filename that should be submitted and optionally which roles a user should have
• POST /api/application/{application} -- for an application submit an archive file

When each application has endpoint it would look like

• GET /api/application/haddock3 -- for haddock3 application returns the config filename that should be submitted and optionally which roles a user should have
• POST /api/application/haddock3 -- submit a haddock3 archive file

Implemented this, see screenshot in PR description, but without GET routes as they are not needed.

[sverhoeven]

There is enough stuff in this PR lets merge it.