Add an HTTP request task type that calls an external endpoint and routes on its response

Problem/Motivation

A workflow cannot call an external HTTP endpoint without code. Today that takes a custom Action run by the action task, or an ECA model. Most BPMN engines ship this step: Flowable has an HTTP task, Camunda an HTTP connector (a REST connector in Camunda 8), jBPM a REST work item handler. Authors coming from them expect to call a web service from the model and route on its answer.

Proposed resolution

Add an http_request task type, in a new orchestra_http submodule:

• Request: method, URL, headers and body, each able to read process variables through tokens. A JSON body can be built from variables.
• Credentials: none, basic, or a bearer token, the secret held by the Key module as orchestra_client holds its own.
• Response: the status code to one variable and the body to another, decoded when it is JSON, with a size cap.
• Answers and failures: a response is an answer, not a failure. The step writes its status code to its outcome variable, so its flows route a 404 or a 409 as they route any outcome. A timeout, a refused connection, a 429 or a 5xx is a failure instead: retryable, so the node's retry policy applies, and once the attempts are used up the step's own choice from #3633763 decides what happens, a failed outcome among the answers.
• Safety: the step calls the servers its author named, whatever a variable holds, because a URL built from variables may come from a form somebody filled in. A token's value is URL-encoded where it goes, so a variable fills a path segment or a query value but cannot add one or change the host. A host a token supplies must be one of the step's allowed hosts. Redirects are not followed. Both http and https are allowed, an intranet service often being served over http; credentials sent over plain http give the author a warning when the workflow is saved. No private-address rule: on an intranet every service is on one, and the allowed hosts already keep a variable from reaching a server nobody named.
• Timeout: a short default, settable per node. A workflow running synchronously makes the call inside the request that advanced it, which the documentation says plainly, pointing at the queued execution mode for slow endpoints.

Remaining tasks

• Done in merge request 735: the task type and its settings form (both modelers build their panels from it), the documentation page, an example_http_lookup workflow in orchestra_examples, and tests against a mocked HTTP client. #3633763 has landed.

User interface changes

A new task type in both modelers. Both also show a warning when a step sends credentials over plain http: the Complete Modeler after a save, and either modeler when the workflow is opened.

API changes

A new task type is a new plugin. The engine gains TaskTypeWarningsInterface: a task type implementing it is asked, through TaskTypeManager::getWarnings(), what to tell the author about a node, and the modelers show it beside the node feature warnings.

Data model changes

None beyond the node's configuration.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. I reviewed it.)